我见过太多工程师用同一种方式评价 AI 编程工具：
“写个 Demo 还行，真正的业务代码根本用不了。”
然后把 Cursor 或 Copilot 关掉，继续修改那份已有八年历史、没有一行注释的 Java 代码。
我理解这种无力感。但越来越觉得，这个判断本身错了。
不是 AI 工具不行，而是我们用错了方式。
一、你真正的问题不是 AI 不够聪明
传统 ToB 项目——ERP、CRM、供应链、财务系统——真正的问题从来不是“缺少聪明的工程师”，而是系统已演变为一个没人完全理解的复杂生命体。
需求文档是三年前的，与当前代码严重脱节；核心业务逻辑散落在多个年代的模块中，靠数据库表隐式耦合；唯一真正懂系统的人早已离职，只留下一句“这块你们自己看看吧”。
在这种环境下修改代码，如同走钢丝：一个看似无关的字段改动，三天后可能在完全不相关的报表中触发 Bug，而根源竟是 2019 年一次“临时修复”。
此时使用 AI 写代码，就像把一个聪明但毫无上下文的新手直接扔进迷宫，告诉他“你看着办”。他确实聪明，但聪明救不了他。
二、Copilot 模式为什么在 ToB 场景失效
过去两年，多数团队采用 Copilot 模式：AI 在工程师编码时提供补全、建议或生成单个函数。
该模式适用于两类场景：一是逻辑清晰、无历史包袱的新功能开发；二是模板化重复任务（如测试用例、CRUD 接口生成）。
但在 ToB 核心战场——遗留系统改造、复杂业务逻辑重构、多模块联动开发中，Copilot 模式几乎必然失效。
根本原因在于：AI 生成代码的质量，高度依赖其可获取的上下文质量。
你给它一个函数，它能写出语法正确、逻辑清晰、单元测试通过的代码；但它不知道该函数在整个流程中的位置，不了解下游调用者的隐含假设，更不清楚某个奇怪 if 判断背后藏着客户特有的结算规则。
结果就是：代码在测试中完美运行，上线后却以完全不可预知的方式出错。
这不是 AI 的问题，而是方法论的问题。
三、换一个思路：从“教 AI 写代码”到“设计让 AI 安全工作的环境”
Harness 的本质
“Harness”源自马具，包括缰绳、马鞍、眼罩、胸甲——它不增强马的力量，而是将力量可靠导向目标工作。
AI 模型亦如此。Claude Sonnet、GPT-5.4 等模型认知能力极强，但若仅打开对话框输入文字，就等于“裸骑”：效果全凭运气。
模型不是不够聪明，而是正在“裸奔”：没有缰绳约束方向，没有眼罩屏蔽干扰，没有人告诉它何时停、往哪走、做完是否需自检。
因此，“Agent Harness”指包裹在 AI 外的完整技术栈，将原始认知能力转化为可靠输出。
Harness Engineering：驾驭工程
Harness Engineering（驾驭工程）是近年工程实践前沿兴起的一套方法论，核心命题只有一句：与其花精力让 AI 更聪明，不如花精力为 AI 构建更好的工作环境。
传统 AI 辅助开发中，人类是指挥官，AI 是执行者，全程人工监督——效率提升上限约为 20%~30%。
Harness Engineering 的目标不同：让 AI 在严格约束下自主完成复杂任务，无需逐行确认，而是通过预设机制确保每一步操作可控。
类比而言：不是放任实习生自由发挥，而是为其配备传感器、自动熔断机制和操作沙箱——只能在沙箱内操作，违规即拦截，错误自动回滚，全程留痕。
在此框架中，AI 存在四大天然缺陷，必须由外部系统弥补：
- 失忆性：每次调用 LLM 都不记得上一步，50 步重构任务到第 30 步时因上下文溢出而“自由发挥”；
- 幻觉式执行：陷入死循环仍自信宣称“这次应该好了”；
- 缺乏安全意识：被赋予数据库写权限就执行，获邮件接口就发真实用户；
- 无状态性：任务中断后重试，可能重复已做操作甚至引发冲突。
Harness Engineering 通过四类控制模块应对上述缺陷：上下文管理、工具安全网关、验证反馈循环、状态持久化。
因此，Harness 不是一条提示词，也不是某个工具，而是一套工程化的控制体系。
六层架构
实践中常见结构可拆分为六层（不同团队表述略有差异，逻辑一致）：
- Loop（循环层）：观察 → 决策 → 行动 → 验证 → 更新，持续推进直至完成；
- Tools（工具层）：支持 AI 读写文件、运行代码、调用 API，不止于“说”；
- Context（上下文层）：精准控制可见/不可见信息，避免过载或猜测；
- Persistence（持久化层）：跨对话、跨步骤保留状态，缓解“失忆”；
- Verification（验证层）：集成自动测试、语法检查、自检机制；
- Constraints（约束层）：明确定义权限、预算、文件范围、敏感信息边界。
该框架虽不复杂，但在 ToB 场景中成效显著。
四、ToB 项目实战：起死回生四步法
以下四步源于真实遗留系统改造项目，非纯理论推演。
第一步：先建“业务护栏”，再动代码
这是最容易跳过、代价最惨重的一步。
许多团队直接将代码喂给 AI，要求“帮我重构一下”，新代码看似整洁，上线一周后客户投诉：特殊结算结果错误。
复盘发现，旧代码中一段“奇怪逻辑”实为某大客户十年前谈判达成的特殊折扣规则，无文档，仅存于代码中——AI 将其识别为冗余并优化删除。
此类事故一旦发生，团队对 AI 的信任即告崩塌。
正确做法是：动代码前，先锁定现有系统行为。
技术上称为 Characterization Tests（特征测试）：不测试“应该怎样”，而测试“现在怎样”。即使某些行为实为 Bug，也先固化，待重构完成后再统一评估是否修复。
进一步，将核心业务规则 DSL 化——用机器可读格式表达规则，而非依赖自然语言文档或员工记忆。
某物流公司耗时三周，为核心运费引擎编写 500 个自动化测试用例，覆盖偏远地区加价、大件分拆、同城当日达折扣等全部特殊场景；随后指挥 AI 重写计费模块，500 个测试全部通过，零业务差错。
三周写测试，三天重构——表面低效，实为最快路径。
第二步：绞杀者模式，拒绝大爆炸
“重写整个系统”是 ToB 项目的古老诅咒。大爆炸式重构失败率极高，并非因工程师不努力，而是将所有风险集中于单一时间点，出错后回退成本巨大。
绞杀者模式（Strangler Fig Pattern）更稳健：新旧系统并行，逐步迁移流量，直至旧系统被完全替代。
借助 AI，该模式可更精细化实施：AI 分析代码库依赖关系，识别可独立剥离模块，生成新实现；同时自动生成“流量回放脚本”，在影子模式下将生产请求同步打向新旧两套实现，仅当输出完全一致时才切换对应模块流量。
每个模块剥离均为低风险小任务。一百个低风险任务，远优于一个高风险大任务。
AI 在依赖分析与测试生成上的效率，可将原本需一个月的前期分析压缩至数天。
第三步：定制化需求，配置化而非编码化
ToB 项目永恒难题：客户定制。A 客户要某格式报表，B 客户要另一格式；A 客户审批流四级，B 客户两级；A 客户导出需加密，B 客户需水印无需加密。
传统做法是来一个需求写一段代码，堆叠大量 if customer == "A" 判断，久而久之形成无人敢动、无人知晓全貌的“意大利面代码”。
Harness Engineering 的解法是：提取差异项，以元数据描述，让 AI 基于统一底座自动生成定制插件。
人类只需定义“A 客户报表需增加 X/Y/Z 字段，格式为 CSV”，Harness 将该描述传给 AI，AI 生成代码、自动运行回归测试、确认不影响其他客户后交付。
原本需三天的定制开发，压缩至 30 分钟；更重要的是，if customer == "A" 消失，取而代之的是结构清晰、可积累、可复用的配置体系——这本身就是核心技术资产。
第四步：让文档活起来
ToB 系统长期痛点：文档永远滞后于代码。写文档缺人力，写了不维护，维护了没人看，最终系统沦为黑盒，知识锁在少数人脑中，人员流动即知识流失。
Harness Engineering 的解法是：让 AI 持续分析代码库，自动生成并更新业务流程图、API 文档、数据字典——文档成为代码的自动衍生物，而非人工负担。
更进一步：将文档中的业务描述转化为可执行测试用例。若代码行为与文档不符，CI 直接报错。文档由此从静态参考资料，升级为一套活的、可验证的系统规格。
当文档与测试合二为一，知识便从个人大脑转移至系统之中，人员流动风险得以有效对冲。
五、这套方法适合谁，不适合谁
Harness Engineering 并非万能药。
最适合场景，恰恰是传统认知中“最难引入 AI”的领域：有明确业务规则的遗留系统改造、多租户 SaaS 规模化定制开发、数据密集型 ETL 管道、合规要求严格的金融与医疗系统。
共性特征：规则清晰（或可被清晰化）、风险高、验证路径明确——这三点正是 Harness Engineering 发挥效力的关键条件。
不适合场景是从零到一的探索型产品：业务规则尚未成型，需求持续变动，缺乏历史约束与明确验收标准。此时前期投入重，收益有限。
简言之：越是“又老又重”的系统，越适合这套方法。表面反直觉，实则因其核心逻辑正是——利用既有规则与约束驾驭 AI。
六、工程师的角色正在改变
Harness Engineering 的普及，正深刻重塑工程师的职业价值。
有人担忧 AI 抢饭碗，但更准确的说法是：工程师的价值重心正在转移。
传统模式中，资深工程师的核心价值常源于对某段代码的熟悉度——他知道每个奇怪判断背后的历史，能在不完全理解系统的情况下凭经验做出正确修改。
在 Harness Engineering 框架下，这类隐性知识将被系统化：通过测试用例、DSL 规则、自动化验证脚本显式表达，沉淀为可积累、可传承的数字资产，而非仅存于个体记忆。
与此同时，一种新价值日益凸显：设计能驾驭 AI 的测试体系与架构约束的能力。
这不再是写代码，而是构建一个能让代码被安全自动生成的环境。它要求深度业务理解、系统性架构思维、将模糊需求转化为精确约束的能力。
直白地说：业务建模能力，比写代码速度更重要。将复杂业务规则抽象为机器可验证的形式，仍是 AI 尚无法替代的人类核心能力。
七、从哪里开始
若你正面对复杂 ToB 系统，不知如何起步，建议只做一件事：
先为核心模块写测试，再谈其他。
无需一步到位设计完整 Harness 框架，不必立即引入复杂 DSL 体系。从一个具体模块入手，用测试将其行为完全锁定。
完成后，你会自然看清：哪些是真实业务规则，哪些是历史 Bug，哪些地方可安全交由 AI 介入。
测试护栏建好，AI 才真正拥有可放手施展的空间。
这个起点，比任何 AI 工具选型讨论都重要。