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