# 为什么有这个项目：从复杂度评估到产品级复刻 关联文档：[`software-project-complexity-in-the-ai-era.md`](./software-project-complexity-in-the-ai-era.md) ## 核心论点 Harness Engineering 不是为了让 `AGENTS.md` 更漂亮，也不是为了把 linter 调得更严。 它真正想回答的是一个更大的问题： > 在 AI Agent 已经能够理解、探索、修改代码之后，软件工程的瓶颈会转移到哪里？ 我的判断是：瓶颈会从“能不能写出代码”，转移到“能不能把复杂系统变成可理解、可约束、可验证、可复刻、可持续演化的对象”。 因此，本项目的落地价值可以概括为一句话： > 把“产品级复刻 + 持续演化”从“精英团队限定”，变成“一个工程师 + 一个 AI Agent 可达”。 这里的“复刻”不是像素级复制，也不是 100% 行为等价，而是在理解一个已有项目、产品或系统之后，提取它的核心结构、核心功能和关键约束，再用新的技术栈、新的工具链、新的工程方法重新构建出来。 本项目存在的目的，就是把这条因果链走通： ```text 复杂度可评估 ↓ 知识可显性化 ↓ 任务可胶囊化 ↓ Agent 可接管 ↓ 结果可验证 ↓ 产品可复刻 ↓ 系统可持续演化 ``` --- ## 一、起点：AI 时代如何评估项目复杂度 在 [`software-project-complexity-in-the-ai-era.md`](./software-project-complexity-in-the-ai-era.md) 中，我把 AI 时代的软件项目复杂度定义为： > 人类与智能体共同驾驭一个系统的成本。 传统指标仍然有用：代码量、文件数、模块数量、耦合度、圈复杂度、依赖数量，都可以帮助我们理解一个项目。 但它们描述的是复杂度的载体，不是复杂度本身。 在 AI Agent 参与之后，更关键的问题变成了： ```text AI 能不能理解它？ AI 能不能探索它？ AI 能不能修改它？ AI 能不能验证它？ 人类能不能低成本信任这个过程？ ``` 因此，复杂度可以被压缩成六个维度。 | 维度 | 它真正问的问题 | | ----- | ------------------------ | | 上下文压力 | 一个任务需要牵引出多大的上下文包？ | | 可提示性 | 功能能否被人类清楚描述，从而被 AI 稳定实现？ | | 探索收敛 | AI 的探索是否有路径、有反馈、有终点？ | | 状态纠缠 | 一个局部改动会不会唤醒整个系统？ | | 暗知识 | 系统正确运行所需的知识，有多少没有被显性化？ | | 验证成本 | AI 写完之后，能否被低成本证明是对的？ | 还有一个重要的分母： > **胶囊化能力（Capsuleability）**：把复杂系统切成可独立理解、修改、验证的小块的能力。 如果一个系统可以被胶囊化，AI 就能局部接管；如果不能，AI 的每次修改都可能变成一次全局冒险。 所以，复杂度的终局指标不是“它有多少代码”，而是： ```text 它能不能被重构？ 它能不能被复刻？ ``` 重构和复刻会一次性暴露系统里的全部问题：上下文是否过大，边界是否清楚，暗知识是否太多，验证是否可信，状态是否纠缠。 换句话说： > 复刻能力，是复杂度的显影测试。 --- ## 二、学徒途径：记录、复制、复现、迁移 这里借用一个“学徒途径”的隐喻。 “学徒”不是指初学者，而是指一种能力结构： ```text 观察 → 记录 → 复制 → 复现 → 迁移 ``` 它的核心不是原创，而是看到一种能力之后，先记录下来，再尝试重现；重现不一定 100% 等价，可以有折扣，但必须抓住核心。 放到工程语境里，“学徒能力”指的是： > 观察一个已有项目，把它拆成可理解的结构，再用自己的语言、工具或技术栈重构一遍，看看能复刻到什么程度。 这正是 AI 时代个人开发者和小团队获得杠杆的关键。 四个动作分别对应 Harness Engineering 的不同能力。 | 学徒动作 | 工程含义 | Harness Engineering 中对应的能力 | | ---- | ---------------- | --------------------------------- | | 记录 | 把项目知识从隐式变显式 | 仓库即记录系统，`AGENTS.md`，SPEC，thinking | | 复制 | 在同一技术栈中复现一个等价系统 | Map not manual，Spec as Product | | 复现 | 在不同时间、环境、团队中重新跑通 | 机械化执行，测试，CI，脚本，约束 | | 迁移 | 换语言、换栈、换场景重构 | Agent readability，结构与具体实现解耦 | 这里最重要的洞察是： > 复刻可以打折扣。 这不是降低标准，而是重新定义目标。 产品级复刻不一定要求： ```text 100% 行为等价 100% 技术栈一致 100% 交互一致 100% 边界 case 覆盖 ``` 它更关心： ```text 核心用户价值是否复刻？ 核心业务流程是否复刻？ 核心数据结构是否复刻？ 关键约束是否复刻？ 质量下限是否被守住？ ``` 如果非要 100% 复刻，AI 接管很容易被少数边界 case、历史包袱和隐式约定拖死。 但如果接受可控的 70%–90% 近似，先复刻核心，再持续迭代，构建速度就会被真正释放。 这也是“学徒途径”的意义： > 先记录，再复现；先相似，再逼近；先可运行，再持续演化。 --- ## 三、从可复刻到可构建 一旦一个项目的“学徒可复刻性”足够高，就会出现连锁反应。 ```text 项目知识被记录 ↓ 复杂度被拆分 ↓ 任务可以胶囊化 ↓ Agent 可以局部接管 ↓ 结果可以验证 ↓ 一个工程师可以复刻产品级系统 ↓ 小团队可以持续演化多个产品 ``` 这条链的关键，不是 AI 有多会写代码。 AI 写代码这件事，已经越来越不是瓶颈。 真正的瓶颈是： ```text 要写什么？ 遵守什么？ 从哪里开始？ 哪里不能动？ 怎样算完成？ 怎样证明正确？ 怎样持续维护？ ``` 这就是 Harness Engineering 要解决的问题。 它不是单次生成代码的技巧，而是围绕 AI Agent 设计一套工程环境，让 Agent 的工作可以被引导、约束、验证和复用。 在这个意义上，Harness Engineering 的目标不是“让一个人偶然做出一个项目”，而是： > 让一个人能够稳定地做出 N 个项目，并且每个新项目的边际成本递减。 这也是“产品级复刻 + 持续演化”的真正含义。 --- ## 四、为什么是现在 这件事在过去并不成立。 早期的 AI 编程工具更像是自动补全、片段生成或局部问答。它们可以提升效率，但很难独立承担一个复杂项目的探索、理解和修改。 而现在的 AI Agent 已经开始具备几个关键能力： ```text 它可以自己搜索代码。 它可以阅读文档和错误日志。 它可以运行命令并根据反馈修正。 它可以跨文件理解调用链。 它可以在多轮尝试中逐步逼近目标。 ``` 这意味着，AI 不再只是一个“代码生成器”，而开始像一个可以被编排的执行主体。 但这也带来了新的问题。 当 AI 能够自己探索时，人的职责不是一步步告诉它怎么做，而是设计一个环境，让它的探索能够收敛。 ```text 入口在哪里？ 约束在哪里？ 规范在哪里？ 测试在哪里？ 失败信号在哪里？ 人类审查点在哪里？ ``` 这正是 Harness Engineering 出现的时间窗口。 如果模型能力还不够强，Harness 只能变成文档整理。 如果模型已经能自主探索，但缺少约束和验证，Harness 就变成必要的工程基础设施。 也就是说： > 当 AI 具备接管局部工程任务的能力之后，真正稀缺的就不再是生成能力，而是约束、反馈和验证能力。 --- ## 五、这就是本项目的宗旨 一句话： > 把 Harness Engineering 从“概念集合”，变成“可复刻的产品构建方法论”。 这个仓库不是为了收集漂亮概念，而是为了验证一件事： ```text 能不能通过一套可沉淀、可执行、可迁移的工程方法， 让 AI Agent 稳定参与产品级软件的复刻与演化？ ``` 因此，仓库中的每个目录都应该服务于同一个目标：降低 AI 接管复杂项目的成本。 | 目录 | 它降低哪类复杂度 | | ------------- | -------------- | | `concepts/` | 提炼核心概念，降低理解成本 | | `thinking/` | 形成个人判断，降低盲从成本 | | `practice/` | 做真实实验，降低空谈成本 | | `tools/` | 把方法变成工具，降低重复成本 | | `works/` | 输出可复刻产物，验证最终价值 | | `references/` | 吸收外部进展，保持系统更新 | | `feedback/` | 记录失败和反例，修正方法论 | | `prompts/` | 沉淀可复用工艺，降低协作成本 | 如果某个目录不能映射到“降低复杂度”的某一段，它就不应该存在。 Harness Engineering 的价值不在于文档数量，也不在于规则数量，而在于它能否持续回答： ```text 这个系统是否更容易被 AI 理解？ 这个任务是否更容易被拆分？ 这个约束是否更容易被遵守？ 这个结果是否更容易被验证？ 这个产品是否更容易被复刻？ ``` --- ## 六、本项目要验证什么 这个项目最终需要接受几个测试。 ### 1. 最小产品级复刻测试 选择一个足够小但完整的产品，例如： ```text 一个 CRUD 系统 一个内容管理工具 一个轻量 SaaS 一个内部运营后台 一个数据看板 ``` 然后尝试从 SPEC、约束、提示词、工具链出发，让一个工程师和一个 AI Agent 完成可运行版本。 重点不是证明 AI 能写代码，而是证明： ```text 从理解到构建，从构建到验证，从验证到迭代， 这整条链是否能被 Harness 化。 ``` ### 2. 折扣复刻测试 复刻不要求 100% 等价，但必须说明折扣在哪里。 ```text 哪些功能被完整保留？ 哪些行为被简化？ 哪些边界 case 被放弃？ 哪些技术栈被替换？ 哪些约束必须保持？ ``` 如果折扣是隐含的，复刻就不可信。 如果折扣是显式的，复刻就是一种产品设计。 ### 3. 递归测试 本项目本身也应该符合自己的标准。 也就是说，另一个人能否基于这个仓库，复刻出一个等价的学习档案、方法论系统或产品构建流程？ 如果不能，这个项目就还没有真正 Harness 化。 --- ## 开放问题 还有一些问题没有答案，但它们正是这个项目值得继续推进的原因。 ```text “产品级复刻”的最小验证案例是什么？ ``` ```text 如果 AI 协作复杂度继续下降，工程师的核心职责会变成什么？ ``` ```text 一个系统的“可复刻性”能否被量化？ ``` ```text 6 维复杂度框架是否完整？是否还缺少 token 成本、模型漂移、工具稳定性等维度？ ``` ```text 本项目能否通过自己的递归测试？ ``` 这些问题不会靠一次思考解决，只能靠不断实践、记录、修正。 --- ## 下一步 这个项目接下来应该做三件事。 第一，选一个最小产品级复刻案例。 不要一开始选择过大的系统。先选择一个边界清楚、功能完整、可以运行、可以测试的小产品。 第二，把方法论具像化。 也就是把复杂度评估、SPEC 提取、任务胶囊化、Agent 执行、验证反馈这些环节，沉淀成工具、模板、提示词和检查清单。 第三，用实践反向修正理论。 如果某个概念不能帮助复刻产品，它就只是概念。 如果某个工具不能降低验证成本，它就只是装饰。 如果某个流程不能让 Agent 更稳定地完成任务，它就不属于 Harness Engineering。 --- ## 结语 AI 时代的软件工程，不只是让 AI 写代码。 更重要的是： ```text 如何让复杂系统变得可描述； 如何让隐性知识变得可记录； 如何让任务变得可拆分； 如何让 Agent 的探索变得可收敛； 如何让生成结果变得可验证； 如何让一个产品变得可复刻、可迁移、可持续演化。 ``` 这就是这个项目存在的原因。 Harness Engineering 的最终目标，不是制造更多文档，而是制造一种能力： > 让一个工程师和一个 AI Agent，能够稳定地理解复杂系统，复刻产品级软件，并持续推动它演化。