👾 一个小小的胜利
内容提要
文章认为软件开发范式已变：中间层从人写规则转为模型理解上下文，实现成本降低，而说清需求与验证的成本上升。平台方不再替业务开发，而是搭建harness，管理上下文、权限、退路与验证。成熟业务应沉淀为代码工具，未做过的才调用模型。模型会标准化部分能力，但责任、接口、标准、成本仍需人兜底。开发者应从写逻辑转向搭台子、攒资产、做判断。
延伸解读
从“写规则”到“管上下文”
文章指出，中间层已从人写规则转为模型理解上下文。过去开发的核心是穷举规则、保证可复现；现在实现成本降低，但说清需求和验证结果变贵。失败也从“一行写错”变成概率性结果。这意味着开发者的重心需从编码逻辑转向设计上下文：明确模型该知道什么、不该知道什么、能做什么、做完留下什么。规则并未消失，只是从代码挪进了上下文。
平台方角色：从代做业务到搭台子
文章认为，平台方不再替业务开发，而是搭建 harness，管理上下文、权限、退路与验证。业务方可自己在平台上跑任务，平台方不必深懂业务，但需确保工具可用、权限拦得住、错误查得出、好坏能量。交付物从“替业务做好的东西”变为“让业务自己能做的东西”。这要求平台方把能力沉淀为可复用的台子，而非一次性项目。
沉淀与现想：token 该花在哪
文章提出两层做法：做过的业务固化为代码、工具、流程，走沉淀层不烧 token；没做过的事才让模型现场推，这里才花 token。跑通后可固化回沉淀层。代码不是不写了，而是从写业务变成写沉淀。文章强调，沉淀是把稳的业务做成资产，补丁则是模型不行时贴一块，模型换代就过期。因此应优先把确定的事攒下来，减少对模型的重复调用。
模型会标准化部分能力，但四样东西仍需人兜底
文章认为，模型越强，harness 零件越少，但责任、接口、标准、账四样不会消失：谁授权、出事谁兜是组织法律问题；模型动不了真实系统，需人接库、钱、车；什么算对由业务定，模型自判偏向自己；token、延迟、预算厂商不管。因此“被吃掉”更像“被标准化”，自建台子的活儿缩到组装和守约束。开发者应把判断权放在该停的地方，并早算 token、延迟、并发等设计参数。
Q&A
为什么说软件开发中“中间层”被模型接走了？
以前中间层是人写的规则（如果这样，就那样），现在变成由模型理解上下文来现想规则。开发者只需把话说明白，规则由模型生成，实现成本降低，但说清需求和验证结果变贵。
平台方在AI时代的新角色是什么？
平台方不再替业务开发具体功能，而是搭建harness（马具），管理上下文、权限、退路与验证，交付“让业务自己能做的东西”，中间翻译环节消失。
什么是harness？它为什么重要？
harness是套在模型身上让它能拉车的一整套东西，核心是上下文——模型做决定时能看到的全部信息（身份、历史、规矩、权限、目标等）。它兜住模型，确保上下文正确、工具可用、权限可控、错误可查、结果可验。
如何降低模型调用成本？
把做过的业务固化成代码、工具、流程（沉淀层），不烧token；只有没做过的事才让模型现场推理（烧token）。这样token只在开发和做新业务时消耗。
模型会取代harness吗？
会变薄但不会消失。责任（授权与兜底）、接口（连接真实系统）、标准（业务定义对错）、账（token、延迟、预算）仍需人负责。模型会标准化部分能力，但自建最后剩的是约束与验证。
开发者应该怎样调整开发方式？
先想上下文再想代码；能确定的事攒成资产；给错留退路（权限、兜底、回滚）；让系统可验证（记录回放、指标导出）；早算钱（token、延迟、并发）；人放在该停的地方做判断。技能从“会操作”转向“会判断”。
