过去一年，很多团队对 AI 写代码的判断经历了一个很快的转弯。一开始大家问的是：AI 能不能写代码？后来问题变成了：AI 写出来的代码，能不能进入一个真实工程系统？
第一个问题看的是生成能力。第二个问题看的是工程能力：需求有没有被保留，方案有没有被验证，测试是不是跟着代码一起变化，E2E 是否真的跑过，改动有没有影响安装、配置、回滚、成本和后续维护。
在 AiKey Labs，我们把这套围绕 AI 编程建立的工程约束叫做 AI Coding Harness。它不是一组更漂亮的提示词，也不是把更多模型塞进同一个流程。它更像一套约束系统：让 AI 可以快，但不能脱离目标；让 Agent 可以并行，但每一步都有验收。
AI 编程真正缺的不是生成，而是验收
AI 很擅长给出一个看起来完整的答案。问题在于，真实软件开发很少只需要一个“看起来完整”的答案。
一个功能上线前，团队会追问：这个实现解决的是用户最初的问题，还是中途变成了另一个更容易回答的问题？测试覆盖了改动路径，还是只覆盖了最顺手的 happy path？E2E 跑的是有真实数据流的场景，还是空数据状态下的自我安慰？
任何 AI 产出都必须能被验收。验收不是最后补一个勾，而是从需求开始进入流程。
验收要从需求开始进入流程。一个需求必须同时存在提供端和验收端：谁负责产出方案、代码、测试和报告，谁负责判断这些证据是否足够。没有验收端的 AI 编程，最后很容易变成一连串看似勤奋的提交。
Harness 要保护用户目标，而不是保护中间方案
AI 编程里最常见的偏移，不是模型完全跑题，而是它把需求改写成了一个更容易完成的任务。
用户说的是“我在长任务开始前想确认所有 Key 都可用”，实现可能变成“加一个检查按钮”。用户真正担心的是长任务中断、额度浪费、失败后无法判断责任。按钮只是一个可能的界面形态，不是目标本身。
AI Coding Harness 要求流程持续保留用户原始目标。方案可以变，技术路径可以变，甚至页面形态也可以变，但不能把用户痛点替换成实现者更熟悉的组件。
上下文纯度比提示词更重要
很多团队会把 AI 效果归因到 prompt。prompt 当然重要，但在复杂工程里，真正决定质量的往往是上下文纯度。
一个长会话里混进了需求讨论、架构争论、临时修 bug、失败日志、旧方案、无关文件和反复返工，模型就会越来越难判断什么是事实，什么是历史，什么是当前必须遵守的约束。
- 方案设计、实现、Review、E2E 验收不一定放在同一个窗口里。
- 关键上下文要沉淀为 SPEC、验收标准、测试报告和决策记录。
- 每一轮返工都要说明它修的是哪个验收失败点。
很多 AI 编程事故不是模型不会写代码，而是它只拿到了当前 20% 的上下文，却在修改 100% 的系统。
多模型不是堆算力，而是分工
我们不认为多模型协作的价值在于“多问几个模型，选一个看起来最好的答案”。那种做法成本高，也容易制造新的噪音。
多模型更适合承担不同角色。一个模型可以偏向方案设计和约束整理，一个模型可以偏向实现和集成测试，另一个模型可以站在 Review 或流程监督的位置，检查任务是否按约束推进。
- 方案 Agent 判断信息是否足够决策。
- 实现 Agent 根据 SPEC 写代码和测试。
- Review Agent 检查代码、架构、测试、异常分支和用户目标是否一致。
- 验收 Agent 关注 E2E、数据流、回归风险和证据是否完整。
SPEC + E2E：让需求变成可检查的东西
AI 编程最怕的不是没有测试，而是测试与需求脱节。一个需求如果不能转成 SPEC，就很难稳定传递给 Agent。一个 SPEC 如果不能导出测试用例，就很难证明它真的可执行。
我们把 SPEC 和 E2E 绑定在一起看：SPEC 用来描述需求、边界、异常分支和验收标准。测试用例从 SPEC 中长出来，而不是在实现完成后补几条。E2E 报告是卡点证据，不是发布前的仪式。
前置验证可以减少后面的返工
很多 AI 编程流程的问题，是太早进入实现。模型很擅长写代码，所以团队会很自然地把“还没想清楚的问题”交给它写。结果是代码越写越多，真正的不确定性却没有减少。
AI Coding Harness 鼓励前置验证：对不熟悉的第三方集成，先做 spike；对不确定的架构方案，先做对照实验和评分；对关键流程，先定义卡点和失败标准。
文件权限错误就是一个典型例子。看到 `EACCES: permission denied`，最直觉的建议往往是“用 sudo 再跑一次”。但这类错误不一定真是权限不够，也可能是文件被另一个 shell、编辑器、索引器或安全软件短暂占用。前置验证要先问清楚：这是 ACL 权限问题，还是文件被占用？
权责合并：设计者也要面对验收
传统流程里，方案、实现、测试、验收经常被拆成不同环节。AI 加入后，如果仍然只把它当作“实现劳动力”，流程会很容易失衡。
一个健康的 Harness 需要把权责重新绑在一起。做方案的人必须提前说明如何验收。写代码的人必须同时提交对应测试。Review 发现问题后，不能只留下评论，还要推动代码、测试或 SPEC 发生变化。
为什么 AiKey Labs 需要自己的 Harness
AiKey 本身就是一个很适合用 AI Coding Harness 打磨的产品。我们处理的是 AI Key、模型路由、成本归因、团队使用、OAuth token 安全、个人与企业场景差异，以及本地代理和长期配置状态。
例如，一个 Team Key 功能不能只看管理员是否能创建配置。成员真正关心的是：我现在能不能用？失败时原因是什么？这个 Key 属于哪个团队、项目或任务？费用会不会算到错误的人身上？
- 用户目标不被实现细节稀释。
- 数据模型长期稳定，可以承接后续版本。
- 个人版和企业版的差异从设计阶段就被考虑。
- 安装、配置、回滚、离线可用性和异常分支一起进入验收。
一个成熟的 AI Coding Harness 应该长什么样
我们现在对 Harness 的判断还在演进，但有几件事已经很清楚。
第一，它需要一个稳定的领域模型。第二，它需要卡点状态管理。第三，它需要证据账本。第四，它需要上下文分层。第五，它仍然需要人。
Harness 不是要把工程师移出流程，而是让工程师从反复盯生成结果，转向设计目标、设定边界、判断证据和做关键取舍。
结语
AI 写代码会继续变强。真正会拉开差距的，是团队有没有能力把 AI 的生成能力接入一个可靠的工程系统。没有 Harness，AI 编程很容易停在演示和局部提效。有了 Harness，它才有机会进入更复杂、更长期、更接近生产环境的软件开发。
我们做 AI Coding Harness，是因为我们不想只让 AI 更快地产生代码。我们想让 AI 参与一套能被验收、能被回归、能被定位和复盘，也能不断学习的工程过程。