1. Harness Engineering 到底是什么，值得花一篇文章讲清楚
先聊个大家都有过的经历。第一次用 AI 写代码，很多人是惊艳的：让它写个排序函数、生成一段正则、补个单元测试，又快又准，感觉“编程要被终结了”。但等它去改一个真实项目的某个模块，翻车速度也快得惊人——改完一个函数，另外三个地方悄悄崩了；问了十轮之后它把最初的需求忘得一干二净；甚至给你 pip install 了一个根本不存在的包。这时候你才意识到，AI 写代码和 AI 交付代码，中间隔着一条巨大的鸿沟。填平这条鸿沟的工程方法，就是我这两年一直在实践的东西：Harness Engineering。这个词可以翻译成“驾驭工程”，也可以叫“AI 编程工程化”，核心就一件事：把 AI 的能力当成生产力，而不是当成彩票。
先给个我自己下的定义：Harness Engineering 是在 AI 辅助编程的语境下，用一套可重复、可验证、可回滚的流程，把 AI 的单次生成能力拼接成稳定交付能力的方法集合。它不是一个具体工具，也不是某种提示词技巧，而是一条贯穿需求、设计、编码、测试、评审全过程的工程纪律。谁适合看这篇？如果你是刚接触 AI 编程不久的新手，靠这篇文章可以绕开那些最砸时间的坑；如果你已经在用 Copilot、Cursor 或各类 Agent 干活，这篇能帮你把“偶尔好用”变成“稳定好用”。下面我会用一个具体的实战项目，把这套方法论完整拆开揉碎讲清楚。
1.1 从“马具”到 AI 编程：Harness 的双重含义
Harness 这个词在英文里的原始意思是马具、缰绳，后来引申出“驾驭、约束、利用”的意思。软件工程领域其实早就用过这个概念，比如 Test Harness，中文一般叫测试夹具，是给被测代码准备的一套运行环境和驱动脚本。为什么叫 Harness？因为被测代码本身不会自己跑起来，你需要造一个架子、一套缰绳去“套住”它，喂给它输入、接管它的输出、检查它的行为。
AI 编程里的 Harness 逻辑完全一致。大模型天生是一匹很有劲的马，但既不懂你的项目规范，也不记得昨天的对话，更不会主动为写错的代码负责。你直接撒手让它跑，它能跑出各种匪夷所思的结果。而 Harness Engineering 要做的事，就是给这匹马拉上缰绳：任务拆解是缰绳，上下文管理是缰绳，自动化测试是缰绳，Git 回滚也是缰绳。每一根缰绳的目的都一样——让 AI 的自由发挥被限制在安全边界内，同时把它最大的优势（快速生成、大胆联想）完整保留下来。
这里要特别强调一点，很多人以为 Harness Engineering 等于“写更好的 Prompt”。其实不对。Prompt 只是单次对话的输入优化，而 Harness 是覆盖整个开发流程的系统设计。同样的 Prompt，你在一个有 README、有测试、有分支管理、有代码评审的项目里用，和在一个什么都没有的项目里用，效果能差好几倍。差别不在 AI，而在外面那层架子。
1.2 为什么现在突然流行这个词：三个绕不开的痛点
AI 编程工具这几年的进化速度有目共睹，但正因为越来越多人把 AI 放进真实项目，三个痛点才被反复放大。
第一个是上下文失忆。大模型的上下文窗口虽然越来越大，但它不等于“记住了整个项目”。一个超过几万行代码的仓库，AI 能看到的只是你塞给它的那部分。更麻烦的是对话拉长之后，它连你自己在前几轮提过的约束都会忘。你会遇到“我明明说了不要用数据库，它第五轮开始给你建表”这种离谱事。
第二个是幻觉。模型生成的是“概率上最像样的文本”，不是“查证过的事实”。所以它会虚构函数名、编造 API、推荐不存在的第三方库。这类问题在代码领域尤其隐蔽，因为 AI 编出来的调用方式常常看起来非常合理，编译不过你才知道上当了。
第三个是连锁破坏。这是最劝退的。AI 单独生成一个函数，质量可能很高；但让它在一个既有系统里做改动，它很难评估改动对所有调用方的影响，经常“改好一点、搞崩一片”。这也解释了为什么很多人最后把 AI 定位成“只能写新文件，不敢动老代码”。
这三个痛点的共同根源是：AI 擅长生成，不擅长负责。工程化恰恰是用来补“负责”这两个字的。Harness Engineering 的思路不是让 AI 更聪明，而是让它每一次输出都有边界、有检查、有退路。
1.3 和 AI Agent、多 AI 协作的关系是什么
最近“AI Agent”“多 AI 协作”两个词热度很高，很多人搞不清它们和 Harness Engineering 的关系。我的理解是这样的：Agent 是执行单元，Harness 是管理体系。
单机 Agent 比如能自己读文件、跑命令、调用工具的编程代理，它的执行力比普通对话强得多，但同样需要被 Harness 约束——给它任务清单，让它按依赖顺序执行，要求它跑完测试再交付，否则它会在错误的方向上越跑越远。多 AI 协作更复杂，一个写代码、一个写测试、一个做代码评审，听起来很美好，但如果角色边界不清晰、共享上下文不一致、产出物没有统一的验收标准，三个 AI 能互相把对方的代码改坏，比一个人干活还乱。
所以我把 Harness Engineering 看成是所有 AI 编程实践的地基。你单用 AI 辅助写代码需要它，你搭多 Agent 协作更需要它。下面这套五步流水线，就是我实践下来最实用的一版骨架。
2. 从需求到交付：我的五步 Harness 流水线
我自己做 AI 辅助开发，不会一上来就打开对话窗口让 AI“写个功能”，而是先走一套固定的流程。这套流程我走了大半年，反复调整之后稳定成五步：规格先行、上下文到位、验证闭环、小步提交、复盘沉淀。每一步都不复杂，但少了任何一步，后面都会加倍还回去。
2.1 规格先行：把模糊需求翻译成 AI 能执行的任务单
让 AI 写代码最常见的失败方式，是给它一个模糊指令：“帮我写个订单模块”“帮我优化一下这段代码”。模型确实能生成点什么，但生成的东西大概率和你脑子里想的不一样。原因很简单，大模型的训练目标是“生成最可能的续写”，不是“读懂你的潜台词”。你觉得“订单模块”应该包含状态机、金额计算、支付回调，AI 觉得有个 Order 类加几个字段就够了。
所以我的第一个习惯是把需求翻译成任务单。一个合格的任务单至少包含几个板块。
| 板块 | 要写什么 | 示例 |
|---|---|---|
| 目标 | 这一段代码要达成什么效果 | 提供用户添加待办事项的命令行入口 |
| 技术约束 | 语言、框架、依赖范围 | Python 3.11，仅用标准库，不引入框架 |
| 输入输出 | 函数签名、文件路径、命令格式 | add <内容>写入 todos.json |
| 边界 | 明确不做什么 | 不做日期提醒，不做优先级排序 |
| 验收标准 | 怎样算完成 | 命令执行后 JSON 文件内容正确更新，pytest 全绿 |
你可以把这个任务单直接粘贴给 AI，也可以作为协作文档放在项目里，让 Agent 自动读取。重点在于让 AI 在动笔之前知道“什么叫作完”。我通常在任务单最后加一句：“请先列出你的实现方案，等我确认后再写代码。”这一步能防止它一上来就闷头写出一堆和项目风格不搭的东西，比写十个提示词都管用。
2.2 上下文到位：别让 AI“裸奔”开工
任务单解决“做什么”的问题，上下文解决“怎么做才贴合现状”的问题。如果你让 AI 改一个函数，却不给它函数当前的实现、调用方的位置、测试文件的位置，它只能靠猜。猜出来的代码也许能跑，但风格、命名、异常处理逻辑很可能和项目格格不入。
我自己的做法是给 AI 的上下文分三层准备。第一层是项目级文档，包括 README、架构说明、AGENTS.md。AGENTS.md 是给 AI 看的工作手册，里面写清楚项目的技术栈、目录结构、代码风格、常用命令，比如测试怎么跑、格式化用什么工具。第二层是相关代码片段，不是把整个仓库丢给 AI，而是精确提供它需要改的那个函数、那一个模块、相关的接口定义。第三层是契约和接口文档，凡是跨模块调用的地方，把签名和约定写清楚，降低 AI 臆造接口的概率。
这里有个很现实的约束：token 和注意力都有限。你一次性给它塞 10 万行代码，它反而抓不住重点，生成质量迅速下降。更聪明的做法是给路径和定位，让 AI 自己按需去读文件，而不是把所有内容堆在对话里。就像你给新同事指路时，说“代码在 src/services/order.py，你重点看 calculate_total 这个函数”，比把整个仓库打印出来扔给他强得多。
2.3 验证闭环：让 AI 自己证明代码是对的
这一步是整个 Harness 流水线的心脏。我把原则定成一句话：没有验证的 AI 代码，一律视为未完成。
实操上，我要求 AI 交付代码的时候必须同时交付测试，并且把运行结果贴出来。注意“贴出来”这三个字很关键。模型经常跟你说“这段代码可以正常工作”，但实际跑一下全是红。所以我会在任务单里写：“请运行 pytest 并把输出粘贴在回复里。如果测试失败，请继续修复直到通过为止。”没有输出，就等于没跑。
验证体系从下到上分四层。第一层是静态检查，比如 Python 的 ruff、mypy，JavaScript 的 ESLint、tsc，先把语法和类型问题挡住。第二层是单元测试，用 pytest、Jest 这类工具把每个函数的输入输出钉死。第三层是集成测试，验证模块和模块之间的配合。第四层是人工评审，AI 代码再漂亮，业务逻辑上的坑也只有人看得出来。对大多数项目来说，前两层是最低配置。只要条件允许，我都建议你让 AI 把一、二层自动化接进 CI，让每次提交自动跑一遍。
2.4 小步提交：给每次 AI 改动上“保险丝”
如果说验证是防止 AI 出错，那 Git 小步提交就是让 AI 出错时能低成本回头。我踩过一次大坑：让 AI 一次性完成一个功能模块的“重构+新增+改bug”，它干得很起劲，改完发现三个老用例挂了，而且根本分不清是哪个改动导致挂掉的。从那以后，我给自己立了规矩：一次只让 AI 做一个逻辑上的变更，一个逻辑一个提交，每个提交信息写清楚“这一笔为什么”。
小步提交还有一个隐藏好处：AI 的上下文窗口有限，任务拆小了，它每一步需要记住的东西就少，失忆的概率骤降。拆成 20 个小任务逐个击破，比 1 个大任务从头做到尾稳定得多。
还有一个血泪经验：AI 改坏代码之后，第一反应不要是“让 AI 接着修”。让模型在自己的错误代码上打补丁，经常越补越烂。正确的姿势是先 git revert 回到最后一个可用节点，再重新发一个更精确的任务单给它。回滚的成本永远低于排查的成本。
2.5 复盘沉淀：把项目经验变成团队的共同记忆
前四步保证单个任务高质量交付，第五步是让这套方法滚起来的关键。每次任务结束，我会花十几分钟把两样东西写进项目文档：一是这个模块的设计决策，比如为什么用 JSON 存储而不是数据库、命令层为什么用 argparse；二是踩过的坑，比如“AI 曾把整个 main.py 写成一个 300 行的 main 函数，记住要在任务单里拆分文件”。
这些文档积累下来，就成了项目的“AI 知识库”。下次无论是同一个 Agent 继续干活，还是换个模型重新接手，只要让它先读一遍文档，它就能快速理解项目约定，产出质量明显比第一次裸聊高出一截。我见过不少团队把所有经验存在老员工的脑子里，人一走知识就没了。而 Harness 的复盘沉淀，是把人和 AI 的协作经验真正沉淀成组织资产。
3. 项目实战：用 Harness 方法从零写一个 CLI 待办工具
理论聊完必须上手。我选一个特别适合练手的项目：用 Python 写一个命令行待办事项工具，支持添加、查看、完成、删除四种操作，数据存进本地 JSON 文件。这个项目规模适中，能完整展示任务拆解、上下文管理、测试闭环的运作方式，又不会复杂到让人失去耐心。下面记录的是我按 Harness 方法完整走一遍的实战过程。
3.1 项目拆解：把“做个待办工具”细化成可验收的任务
如果直接把“帮我写一个命令行待办工具”丢给 AI，它大概率会给你生成一个 main.py，把所有逻辑塞进一个文件，然后说“完成啦”。用 Harness 的思路，我会先把项目拆成五个任务，每个任务都有明确产出和验收标准。
| 任务 | 内容 | 验收标准 |
|---|---|---|
| T1 | 初始化项目结构和 README | 目录包含 app 包、tests 包、requirements.txt，README 写清楚基本用法 |
| T2 | 数据层：TodoStore | 提供 load、save、add、list、complete、remove 方法，数据自动持久化到 todo.json |
| T3 | 命令层：CLI 入口 | 支持 add、list、done、rm 四个子命令，参数和输出符合预期 |
| T4 | 测试层 | pytest 覆盖数据层和命令层正常与异常逻辑，测试全绿 |
| T5 | 文档补全 | README 更新完整使用说明，AGENTS.md 记录常用命令和代码约定 |
拆完之后，每个任务的提示词就有了抓手。比如 T2，我不会说“写一个存储类”，而是说“实现 TodoStore，负责读写 todo.json。load 时如果文件不存在返回空列表；save 保证原子写入。接口签名是 add(content: str) -> dict”。这样 AI 不需要猜，直接照着接口实现即可。
3.2 第一轮实操：从零搭建脚手架
第一轮我让 AI 只做初始化，提示词大概是这样的：
请帮我创建一个 Python CLI 项目的脚手架。要求： - 目录结构：app/ 存放业务代码，tests/ 存放测试 - app/__init__.py、app/cli.py、app/storage.py 先创建空文件 - 使用 argparse 解析命令行参数 - 不引入第三方依赖，只用 Python 标准库 - 创建 README.md，只写项目简介和一条运行示例 - 列出你准备创建的文件清单，确认后再动手这里刻意限定了“只用标准库”，因为待办工具用文件存 JSON 完全够用，引入数据库或第三方框架纯属过度设计。AI 生成的脚手架基本符合预期，但有一个典型的 AI 痕迹：它在 README 里额外写了一堆 roadmap、contribution 之类的占位内容。这无伤大雅，不过也说明 AI 默认“往多了写”，需要人工收敛。
第一个值得记录的点是：如果任务单里没有“确认后再动手”这句，AI 会直接把所有文件写完，根本不给你确认方案的机会。任务拆解的本质不是让 AI 少干活，而是让每个关键决策点都有人的确认。
3.3 第二轮实操：实现核心逻辑与数据持久化
第二轮实现数据层和命令层，任务单我拆成两个对话分别进行。数据层的提示词如下：
实现 app/storage.py 中的 TodoStore 类。 - 初始化参数是文件路径，默认 todo.json - load() 读取文件并返回列表，文件不存在返回空列表 - save(todos) 把列表写入文件，要求先写临时文件再改名，避免中途崩掉损坏数据 - add(content) 生成新待办，格式 {"id": 1, "content": "xxx", "done": false, "created_at": "2025-..."} - complete(todo_id) 把对应待办 done 置为 true，找不到抛 ValueError - remove(todo_id) 删除对应待办，找不到抛 ValueError - id 自增，删除后不重复使用重点解释两个设计细节，也是我给 AI 的约束来源。第一是“先写临时文件再改名”，这叫原子写入，防止程序写一半崩溃导致 JSON 文件损坏。第二是“删除后 id 不重复”，保证已有的 id 可以安全用作业务标识。这些约束如果不写进任务单，AI 大概率会写出“删了再添加 id 就从头算”的实现，短时间内没问题，后面做同步或者联调就会埋雷。
命令层让 AI 基于 TodoStore 实现 argparse 子命令。这一轮 AI 生成的代码质量已经比较稳定，因为它有了明确的接口和存储层约束。实际跑了一遍，add 和 list 正常，done 和 rm 的参数校验也符合预期。这里有个小意外：AI 实现的 done 命令输出格式和我想要的略有出入，我没让它删掉重写，而是直接加了一条“输出统一为中文，如 已完成: id 内容”的约束，让它小步修正，避免大改引入新问题。
3.4 第三轮实操：让 AI 补测试并跑通验证闭环
代码能跑只是第一步，按照 Harness 的规矩，没有测试验证的代码等于没写完。第三轮提示词如下：
为 app/storage.py 和 app/cli.py 编写 pytest 测试。 要求： - 测试文件放 tests/ 目录 - storage 测试用 tmp_path 创建临时目录，不要污染真实文件 - 覆盖正常路径：add、list、complete、remove - 覆盖异常路径：complete 不存在的 id、remove 不存在的 id 应抛出 ValueError - 运行 pytest，把完整的测试输出粘贴回来这轮实操暴露了一个经典问题：第一次生成的测试有两条没过，原因是 AI 在测试里用了绝对路径 /tmp/todo.json，而不是 pytest 的 tmp_path 临时目录，结果多个测试互相污染数据。这正是 harness 验证闭环的价值——如果我不要求它跑测试并贴输出，这个问题根本不会暴露，而会变成将来莫名其妙的“测试偶尔绿偶尔红”。
看到失败之后，我没有直接改代码，而是把 pytest 的输出原样贴回给 AI，让它自己定位并修复。它很快换成 tmp_path fixture，第二次跑全绿。这里也印证了我前面说的：AI 犯错不可怕，可怕的是犯错没被抓到。验证闭环的意义就是把“我觉得没问题”变成“我有证据证明没问题”。
3.5 工具选型参考：IDE 插件、终端 Agent、多 Agent 平台怎么选
实战走完，顺便聊聊用到的工具和可选替代品。工具永远不是重点，流程才是，但合适的工具确实能让你少操很多心。我把常见选择分成三类。
第一类是 IDE 内嵌的 AI 辅助。比如 VS Code 和 PyCharm 上的 Fitten Code，以及 Copilot、Cursor、Windsurf 一类的方案。这类工具适合绝大多数日常编码场景，交互轻、上手快、和编辑器深度融合。我自己的习惯是：改函数、生成测试、写注释这类小任务直接用 IDE 里的助手，效率最高。Fitten Code 胜在轻量和对国产 IDE 的适配，Copilot 胜在生态成熟，Cursor 如果你愿意整 IDE 迁移，体验也很完整。
第二类是终端 Agent，比如 Claude Code、OpenAI Codex CLI、各种开源的 coding agent。它们能自己读文件、跑命令、改代码、看测试结果，更适合“给我把某个功能从头实现完”这种批量任务。我一般会在任务边界清晰、需要多轮文件操作时切换到这类工具。用终端 Agent 最需要注意的是：必须给它指定可访问的目录，并明确禁止它改动哪些文件，否则它可能顺手帮你“重构”了不该碰的模块。
第三类是多 Agent 协作平台，CrewAI、AutoGen、LangGraph 这类。说实话，普通项目我不推荐一上来就用。多 Agent 会引入通信开销、上下文同步、结果冲突一系列新问题，如果没有足够成熟的 Harness 流程，三个 Agent 的产出大概率不如一个人加一个 Agent。只有当你确实需要“写代码的 Agent、写测试的 Agent、评审的 Agent”并行协作，而且有清晰的验收体系时，才值得上这类方案。
三类工具可以混用。我用 IDE 助手干细活，用终端 Agent 干粗活，用 Git 的分支和 CI 把所有产出管起来。这个组合也是我推荐大多数个人开发者和小型团队起步的标配。
4. 高频翻车现场：五个坑和对应的排查思路
哈里斯工程听起来很顺，但真用起来，几乎每天都能碰到新问题。这款挑五个我踩得最深、也最有代表性的坑讲讲，每个都附上我的排查思路和解决办法，希望能帮你少走几个月的弯路。
4.1 AI 编造包和 API，装了不存在的依赖
这是最让新手崩溃的问题，没有之一。它看起来特别真实：AI 推荐你 pip install 一个名字很正常的包，然后 import 一个“应该存在”的模块，结果 pip 报错或者运行时报 ModuleNotFoundError。我遇到过 AI 让我用from utils import retry，但这个 utils 根本是它编出来的。还有个更隐蔽的变种：包真实存在，但 AI 用的 API 版本不对，比如某些函数是 2.x 才有，项目装的是 1.x。
排查思路分三步。第一，凡是 AI 建议安装的新依赖，先手动去 PyPI 或官方文档确认包名和最新版本，别急着装。第二，提示词里明确“优先使用项目已有依赖，新增依赖需说明理由并经过确认”。第三，依赖锁定，用 requirements.txt 加固定版本号，不要用不锁版本的宽泛写法。这三个习惯能挡住九成依赖幻觉。
4.2 重构一个函数，结果整条业务链路崩了
单看 AI 改的那个函数，逻辑似乎没问题，但它没意识到这个函数被另外五个地方调用，调用方依赖的返回值和异常行为全变了。这类回归问题最阴险，因为通常不在改动的当时报错，而在运行时才炸。
我的防线是双层的。第一层：任务单里强制加一条“不得破坏现有测试”，然后把测试套件跑起来作为验收条件。第二层：对小步提交的严格执行，让 AI 一次只改一个点并用 git diff 检查改动范围。一旦发现改动范围超出了任务单描述，我直接让 AI 停下，先解释清楚为什么动了范围外的代码再说。很多问题其实在 diff 阶段就能拦下来。
| 现象 | 根本原因 | 排查顺序 |
|---|---|---|
| 改动后其他模块报错 | 调用方依赖被破坏 | 先看 git diff，再跑全量测试，最后定位失败用例 |
| 老用例挂了但新功能正常 | 回归未覆盖 | 检查测试是否覆盖调用方行为，补测试后让 AI 重新实现 |
| 运行时才炸、编译不报错 | 数据契约变化 | 重点检查函数签名、返回值结构、异常类型 |
4.3 对话拉长后 AI 失忆，开始自嗨跑偏
对话超过几十轮之后，模型会逐渐淡忘早期设定。症状是这样的：最初说好的技术栈是 Python，第五轮它开始聊 Go 的实现；前面约定“不做优先级”，后来说着说着自己加了优先级字段。这本质上不是模型变笨了，而是长对话中信息互相干扰的必然结果。
我的解决办法很朴素：把重要约束全部落盘到文件里。项目根目录放 AGENTS.md，里面写死技术栈、代码风格、禁止事项；每个功能的约束写进任务单，新开一个对话时就先把任务单和 AGENTS.md 喂一遍。永远不要指望 AI 在长对话里记住所有约定，人开会都要记纪要，AI 也一样。还有一个小技巧：一个任务开一个会话，任务结束就归档，不搞超长会话硬撑。
4.4 过度设计：10 行功能写出 200 行抽象
AI 的训练数据里充斥着各种“最佳实践”，于是它写代码时默认你会需要抽象基类、策略模式、工厂模式。我让 AI 写一个读配置文件的函数，它给我建了一个 ConfigLoader 基类加了三个子类，还配了异常体系和日志装饰器。这样的代码不能说错，但对小项目纯属负担。
对付这个毛病，最有效的是一句话写进任务单：“保持实现简单直接，遵循现有代码风格，不过度设计。”如果它还是写复杂了，就在评审环节要求它精简。记住一个原则：AI 生成代码的抽象水平应该由你决定，而不是由训练数据里的均值决定。
4.5 多 AI 协作互相踩脚，合并冲突不断
多 Agent 并行的时候，最常见的场景是两个 Agent 同时动了同一份文件，一个新增了函数，另一个重构了同一个模块，合并时冲突一大片。更糟的是 Agent A 更新了接口，Agent B 不知道，写出来的调用方代码在合并后直接编译失败。
解决的核心思路是物理隔离加契约先行。物理隔离：让每个 Agent 在各自的 git 分支上干活，合并之前先跑一遍全量测试。契约先行：模块之间的接口必须提前在文档里定死，别人只准调用不准修改。任务看板也是好东西，每个 Agent 开工前先看自己的任务边界，避免和别人的任务重叠。我用这套组合拳试过三 Agent 协作写一个中型模块，冲突率明显下降。
5. 我的个人体会和一个诚实的建议
写了这么多，最后说几句不掺水的个人体会。Harness Engineering 这套方法给我最大的改变，不是 AI 生成的代码质量变高了，而是我终于敢对 AI 的产出负责了。以前让 AI 改完代码，我心里打鼓，不知道它改了哪里、有没有破坏东西；现在每轮改动都有任务单、测试输出和 diff 记录，即使出问题，我也知道问题出在哪个环节，回滚哪里、修哪里，清清楚楚。
诚实的建议是：别看完这篇文章就去买各种 AI 工具，先把流程跑通。拿一个非核心的小项目，按第五步的五步走一遍，拆任务、喂上下文、跑测试、小步提交、复盘沉淀。跑通一次，你就理解这套方法的真正价值了。之后再逐步引入更复杂的 Agent 和多 Agent 协作，你的掌控力是完全不一样的。工具会迭代，模型会换，但“把 AI 当作需要驾驭的生产力”这个思路，在未来很长一段时间里，都会是 AI 编程工程化的主线。
