夜雨聆风
我见过最危险的AI Coding方式
去年底，一个做电商的朋友跟我讲了一件让他后怕的事。
他们团队引入了AI Coding，兴冲冲地让AI帮忙重构一个核心接口。
Prompt写得很勤快："你是一个资深Java工程师，帮我优化这段支付校验逻辑，要求高性能、低耦合。"
AI给出了代码，看起来干净整洁，逻辑也挺清晰。
测试用例跑了，没问题。
上线了。
然后，凌晨两点，报警短信炸了。
生产环境上有一批金额大于1000元的订单，校验被直接跳过了。
损失不敢细说。
复盘的时候他们发现，那段AI生成的代码，在逻辑上确实"优化"了——它把一个历史遗留的条件判断给合并简化了，结果误删了一个关键的边界条件。
而这个边界条件，根本没有写在他们给AI的需求里。
AI不知道，也没有地方让它知道。
这不是AI的错。
是他们没有给AI装上"缰绳"。
大模型像一匹快马，但快马需要驾驭
最近有个词越来越热——Harness Engineering。
直译过来叫"驾驭工程"，或者更粗糙一点，叫"给AI套缰绳"。
Harness原本是马具的意思。
一匹好马，跑得快，力气大。
但你不能只是拍拍它屁股说：兄弟，冲！
你得给它方向，给它边界，给它反馈通道。
跑偏了能被拉回来，踩过的坑下次不再踩。
这套东西，放到AI身上，就叫Harness。
Claude Code、Codex、Cursor这些工具，现在已经越来越强了。
但强，和稳，是两码事。
你给AI一个模糊需求，它会立刻动手，写得飞快，看起来好极了。
结果交到测试手里，十个边界场景，错了七个。
问题不是AI蠢，是它根本不知道你脑子里藏着哪些"不言自明的规则"。
所以，2024年最大的认知升级，不是"要不要用AI写代码"，而是：
怎么用正确的工程架构，让AI稳定、可控地交付企业级代码。
AI Coding为什么会频繁翻车
在我们讲怎么做之前，先把问题说清楚。
AI Coding翻车，通常有三个根本原因。
第一个：需求根本没说清楚。
人类在对话框里随口说一句"加个接口"，AI就开始写了。
它不知道这个接口要兼容哪些老版本，不知道异常要怎么处理，不知道哪些字段是敏感的，也不知道你的验收标准是什么。
AI写的代码，是它理解里的最合理版本，不是你脑子里的版本。
两个版本之间的差距，就是事故的来源。
第二个：没有工程契约，AI凭感觉行事。
这个是90%人忽略的问题。
很多团队觉得，只要告诉AI"要写单测"、"遵循项目规范"就够了。
但这些话，对AI来说是虚的。
它不知道你说的"覆盖率要80%"是指哪些模块，不知道你的"错误码规范"具体是什么，也不知道"禁止跨包调用"的边界在哪里。
没有具体的、可验证的工程契约，AI只能靠猜。
而猜，在生产代码里，代价很高。
第三个：AI既是运动员，又是裁判。
让同一个AI自己写代码、自己跑测试、自己宣布"完成了"，是最危险的模式。
它会护短。
它会觉得"差不多可以了"、"这个边界场景应该不会出现"。
如果没有独立的验证机制，这些"差不多"最终都会变成生产事故。
一套真正能用的企业级Harness架构
要解决上面三个问题，你需要的不是更好的Prompt，而是一套有层次的工程架构。
这套架构，核心分三层。
第一层：人类需求层。
第二层：工程契约层。
第三层：代码执行层。
每一层都有它的职责，缺一不可。
下面我们逐层拆解。
第一层：人类需求层——先想清楚，再动手
这一层的核心原则只有一句话：
人类负责想清楚方向，AI负责把方向翻译成工程动作。
很多人觉得，AI那么聪明，稍微说一下它就能懂，没必要写那么细。
错。
AI的"聪明"，是在信息充分的条件下展现出来的。
你给它的信息越模糊，它的输出就越随机。
所以第一步，是让人类先把需求落成一个可以被"交接"的文档。
这个文档不需要很长，但必须回答清楚以下五个问题：
1. 这个需求为什么要做？（背景和目的，让AI理解业务意图）
2. 这次做什么，不做什么？（明确边界，防止AI自作主张扩大范围）
3. 输入和输出是什么？（接口数据结构、格式、约束）
4. 核心业务流程是什么？（尤其是异常分支，必须写出来）
5. 验收标准是什么？（能被验证的、具体的，不是"功能正常"这种废话）
当你写完这五点，你会发现一件事：需求在你脑子里的那个版本，和写出来的版本，往往不一样。
写的过程，本身就是在帮你理清楚自己到底要什么。
这一步，不要交给AI来做主，交给人类自己完成。
第二层：工程契约层——从业务语言翻译到工程语言
有了需求文档，下一步不是马上写代码。
中间还需要一个翻译过程。
因为业务语言和工程语言，是两个体系。
业务方说："新增校验能力，失败时给前端异常提示。"
这句话够了。
但AI要写代码，还需要知道：改哪个模块、新增什么接口、错误码怎么定义、测试要覆盖哪些场景、哪些架构规则不能破坏。
这层翻译，就是工程契约层要做的事。
在这一层，AI可以起草，但人类必须审批。
具体来说，AI会基于你的需求文档，生成一份工程设计文档，包括：
接口契约：入参、出参、错误码、幂等性要求。
任务拆分：具体到哪个文件、哪个方法需要新增或修改。
测试用例设计：正常路径、边界条件、异常场景，逐一列出。
架构约束清单：本次改动不能违反的项目规范。
完成标准（DoD）：测试覆盖率要求、静态扫描通过、接口文档更新等。
这份文档，就是"写代码前的工程合同"。
它的价值在于：它把隐性规则变成了显性约束。
AI在写代码的时候，不是靠猜，而是对着这份合同执行。
违反了合同里的任何一条，就是Bug，就要打回重写。
第三层：代码执行层——不让AI又当运动员又当裁判
有了工程契约，AI终于可以开始写代码了。
但这一层，有个关键设计：把角色拆开。
不要让一个AI Agent从头写到尾、自己测、自己宣布完成。
你需要最少三个角色：
实现Agent：负责按照工程契约写代码和单测。
测试Agent：负责对照工程契约验收——每个验收标准，都要找到对应的代码证据。
架构Agent：负责检查这次改动是否破坏了项目的架构原则——错误码规范有没有遵守、有没有非法跨包调用、依赖方向有没有反转。
加上机器自动化检查：编译是否通过、单测覆盖率是否达标、静态扫描有没有高危告警。
这四个验证机制叠加在一起，才能覆盖住AI可能犯错的大多数场景。
当然，还有最后一关：人类基于证据来做最终验收。
注意，是"基于证据"。
不是让人类重新过一遍所有代码，而是让人类看：
测试Agent说它通过了吗？架构Agent有没有发现问题？机器检查的覆盖率多少？
如果这些证据都指向"没问题"，人类只需要确认一下，就可以合入。
把三层架构串成一条自动化流水线
把上面三层压缩成一个可以执行的工作流，大致是这样的：
第一步：产品/研发写清楚需求文档，团队内部对齐。
第二步：把需求文档丢给AI，让它结合项目现有的架构规范，和人类确认理解是否一致。
第三步：人类批准后，AI把需求文档翻译成工程设计文档（Spec文档）。
第四步：人类审核Spec文档，确认和原始需求对齐，批准开始Coding。
第五步：实现Agent按Spec写代码，写完自动触发Harness Check——编译通过、覆盖率达80%、静态扫描无高危问题。
第六步：Harness Check不通过，打回实现Agent修改；通过后，触发测试Agent和架构Agent。
第七步：测试Agent逐条核查验收标准；架构Agent检查是否违反项目架构原则。
第八步：双Agent全部通过，最终结果呈现给人类验收；任一不通过，打回修改，直到通过为止。
第九步：如果某个问题被AI反复踩坑（打回超过N次），自动把这个偏航记录写入项目的经验库，下一次同类需求开发时，经验库内容自动进入AI的前置规则。
这最后一步，才是Harness和普通AI Coding最本质的区别。
不只是让AI把这次任务做完，而是让AI的每一次犯错，都变成下一次不犯的防线。
为什么这套架构没有想象中复杂
看到这里，你可能会觉得：这也太重了，我一个人或者一个小团队，能搞得起来吗？
其实，搭建这套架构，比你想象的轻得多。
需求文档：就是一个Markdown文件，五个问题，写完可能只需要半小时。
工程契约：让AI来起草，人类负责审，不需要从零手写。
实现Agent：Claude Code、Cursor这些工具，本来就在做这件事，你只需要给它正确的上下文。
Harness Check：大多数成熟项目都已经有CI流水线、单测框架，这是复用，不是新建。
测试Agent和架构Agent：两个专门的AI角色，写两套提示词，分别跑就够了。
经验库：一个文本文件，把踩过的坑记录进去，每次Coding时带上它。
整套下来，最难的不是技术，是习惯的改变。
从"随口说一句让AI帮我写"，变成"先想清楚、再契约化、再执行、再验证"。
这个思维转变，才是门槛所在。
未来会怎样变化
有一个趋势越来越清晰。
AI Coding的下半场，真正重要的能力，不再是"我能不能亲手写出这段代码"。
而是：
我能不能把一个模糊想法，变成一份清晰需求。
我能不能把需求，变成可执行的工程契约。
我能不能设计一套反馈系统，让AI犯错以后，下次永不再犯。
这三件事，不是AI来做的，是人类来做的。
AI负责执行，人类负责定方向、设边界、建反馈。
以前，写代码的价值在于能写出来。
未来，写代码的价值，在于能设计出让AI写得又快又稳的系统。
这是一个巨大的迁移。
迁移得早的人，在这场变局里会有很大的先发优势。
而开始的门槛，其实不高。
一份五点式的需求文档，一个Spec模板，一套Harness Check规则。
先建起来，再迭代。
如果这篇文章对你有帮助，点击右下角"推荐"，让更多人看到。
关注「飘雪思考」，每周更新职场干货与底层思维，和10万+读者一起成长。
结尾互动
💬 你怎么看？ 你现在用AI写代码，是直接用还是有自己的一套工作流？有没有踩过坑？
欢迎在评论区留下你的想法，我都会看的。
📌 收藏这篇文章，下次需要在团队里推AI Coding规范，直接翻出来用。
觉得有用就转发给朋友，说不定正好帮到在用AI写代码的人。
