AI 工具使用的一些反思：从知识到结构，再到约束

问题不在“AI 会不会写”

最近这段时间，我一直在用 Codex、Claude Code 这些工具来做项目，包括搭建自己的知识库、做项目迁移等等。一开始我其实是把这些事情当成“怎么用 AI 写代码”，但做到一半之后，我发现问题完全不在这里。

很多时候不是 AI 做不到，而是我没有给它一个可以稳定工作的环境。所以最后的结果就是：生成是能生成，但会偏、会乱、会越来越不可控，然后需要我大量手工去修。

这一点其实是我自己踩了不少坑之后才慢慢意识到的，同时也是在反复看了一些文章之后，才逐渐有了一个比较清晰的认知。比如 Andrej Karpathy 在 X 上关于 AI workflows 的讨论，以及 Harness Engineering 这篇文章，其实都在讲类似的一件事：AI 的问题不是能力，而是环境和约束。

也是在这些基础上，我才慢慢把自己的这些零散经验，整理成一个稍微能说清楚的结构。

AI 的问题不是能力，而是环境和约束。

第一层：知识层

一开始最基础的，其实还是“知识”。这些东西在 AI 出现之前就存在，比如 PRD、需求文档、PR、笔记、决策记录等等。这些都是零散的，但也是整个项目最真实的来源。

以前我们是靠人脑去读这些东西，然后在脑子里形成一张结构图，知道哪些东西有关联，哪些地方可以动，哪些地方不能动。但 AI 并没有这个能力，如果你只是把这些零散的知识丢给它，它是能理解一部分，但这种理解是不稳定的，而且随着上下文变长，很容易出现偏移。

所以光有知识是不够的，这一层只能算基础，但本身是不可用的。

第二层：结构层

然后我慢慢意识到第二层，也就是结构层。其实这一层在 Harness 这个概念被强调之前，就已经以另一种形式存在了，比如 repo-specific 这种思路，本质上就是在解决同一个问题：让 AI 能够更快理解一个具体项目。

也就是说，你要给它一套针对这个 repo 的“说明书”，告诉它这个项目怎么读、模块是怎么分的、默认路径在哪里、哪些地方是关键、哪些地方容易出问题。这些东西其实就是结构层的雏形。

后来我再去看一些知识库相关的文章，他们会更明确地把这一层抽象出来，比如项目地图、模块划分、依赖关系、文件职责、影响链路等等。本质上是在做一件事：把“我脑子里的理解”，变成一个明确的结构。

这一点我这段时间吃了很大的亏。我一开始是让 AI 自己去“看项目”，但它只是粗略地读了一下，并没有真正建立结构认知。结果就是后面所有生成都会有偏移，而且这种偏移会越来越严重，最后变成我需要不断手工修。

所以现在反过来看，我觉得这一层其实是整个系统的基石。你必须先把项目结构建立清楚，让 AI 不再“猜”。如果没有结构，知识是不可复用的，AI 的理解也会是不稳定的。

第三层：约束层

在结构之上，就是第三层，也就是约束层，这一层其实对应的就是现在大家在说的 Harness Engineering。

但我自己踩的一个很大的坑是，我一开始是“跳过结构，直接做约束”。也就是说，我很急于把整个流程做成一个闭环，想要定义规则、定义执行方式、定义验证机制，让 AI 一步到位地完成任务。

但实际上，当结构没有建立好的时候，这些约束是没有基础的。AI 对项目本身都没有稳定认知，你再去加约束，它只会在一个模糊的理解上被限制，最后结果反而更奇怪。

所以我后来才意识到，这些步骤其实是缺一不可的，而且是有顺序的：你必须先有结构，才能谈约束。

约束本质上不是让 AI“更聪明”，而是让它“不要乱做”。比如哪些模块不能改，哪些接口必须保持一致，哪些行为必须保留，什么情况下才算完成任务。这些都是在结构已经明确的前提下，进一步限制它的行为。

而且我慢慢发现，这里的约束其实可以分成两种。一种是全局的，比如项目结构、依赖关系，这些是比较稳定的，是整个项目的基座。另一种是具体链路的，比如某一个功能从入口到结束这一整条链路，哪些步骤必须保留，哪些可以改，哪些不能破坏，这种是随着任务动态变化的。

我一开始其实是把这两种东西混在一起了，但后来发现应该拆开看。结构是长期维护的，而链路约束是执行任务时不断补充的。

再往后的几个问题

表达能力

再往后一个我感受特别深的点，其实是表达能力。

我现在的问题不是我不理解这些，而是我表达不出来。我脑子里知道应该怎么做，但我给 AI 的指令是模糊的，比如“帮我迁移这个项目”“优化一下这个功能”，这种表达本身就是不完整的。

而 AI 不会帮你补全你没说清楚的东西，它只会按你给的信息去推理。所以如果你给的是模糊目标，它就会在模糊空间里生成，结果自然就会偏。

所以我现在越来越觉得，在 AI 工程里，表达能力甚至比理解能力更重要。你必须把你的理解，转成结构化的表达，让 AI 可以执行，而不是让它去猜。

约束不是越多越好

还有一个让我比较困扰的问题是，当你加了很多约束之后，AI 会变得很“死”，不太会主动扩展。我现在的理解是，这其实是一个平衡问题。

有时候你需要让它自由分析，这是探索阶段；有时候你已经明确结构和规则了，就必须强约束，这是执行阶段。如果一直用一种方式，要么太散，要么太死。

闭环和验证

最后一个很重要的点，就是闭环。

现在很多人都在强调 AI 的生成能力，但我越来越觉得，生成不是关键，关键是你怎么验证，以及怎么让整个流程闭环。

比如我现在在看一些前端的 E2E 测试，本质上就是在解决这个问题：生成之后，怎么确认它是对的，而不是靠人去一点点检查。如果没有这一层，前面做再多结构和约束，其实都还是不完整的。

最后收一下

所以如果让我现在总结的话，我会觉得整个事情其实可以从三个层面去理解。

第一层是知识层，也就是所有零散的信息，这是基础，但本身是不可用的。
第二层是结构层，这一层其实从 repo-specific 这种思路就已经开始出现，本质是把知识组织成模块、依赖和链路，让 AI 可以理解项目。
第三层是约束层，也就是 Harness Engineering，在结构之上限制 AI 的行为，确保它在执行任务时不会偏。

而我自己踩的最大的坑，就是一开始试图直接跳到第三层，想快速建立闭环，却忽略了第二层的搭建，结果就是 AI 对项目理解不清，后面的所有生成都在偏。

我现在真正想固定下来的东西

我现在的一个很明确的感受是，这些所谓的“知识库方法”、“Harness 工程”，其实都只是一些概念。真正重要的不是去套用某一套模板，而是你自己有没有一套能理解、能表达、能复用的方法。

很多人会直接用现成的模板去搭，但我现在觉得，这些东西未必适合你的项目。因为你才是最了解你项目的人，结构和约束本身就是项目的一部分，不是可以完全外包的。

而且这三个层面本身，也不是我凭空想出来的东西。它们本来就是很多优秀实践、博客文章和项目总结里反复出现的几个核心视角。包括我前面提到的那些文章，其实也都已经在各自的语境里把这些意思讲出来了。我做的更多只是把这些公开分享里已经很有代表性的观点，结合自己做项目时踩过的坑，再重新理解了一遍。

我觉得它们之所以有代表性，是因为至少能先把整个事情的大框架说明白：知识、结构、约束，这三层基本能把复杂项目里 AI 为什么会偏、为什么会乱、为什么会失控这件事讲清楚。

当然，如果再往下细分，这里面还有很多可以继续展开的地方，而且这些东西最后一定还是要根据具体项目去拆。因为每个项目的结构不一样，主线不一样，风险点也不一样，所以真正落地的时候，不可能只靠一个通用模板就解决。大框架可以通用，但具体怎么拆、怎么讲、怎么约束，还是得回到项目本身。

我现在还有一个感受特别明确，就是如果你真的懂这个项目，其实你应该尽量把自己想说的话都说出来，然后再让 AI 去帮你整理，而不是反过来，一开始就只给它几个很短、很模糊的词，让它替你补全。因为你脑子里真正知道的东西，往往比你一句指令里写出来的多得多。如果你不把这些东西尽量说全，AI 最后整理出来的也只能是一个不完整的版本。

所以我现在更想做的事情，不是去找更多工具，而是把这一整套思考顺序固定下来。也就是说，当我下次接一个新项目的时候，我不是边做边想，而是一开始就知道我要怎么去建立认知、怎么拆结构、怎么定义约束、怎么让 AI 去执行，以及最后怎么验证。

如果这套东西能稳定下来，我觉得 AI 才真正能变成一种工程能力，而不是一个随用随乱的工具。