AI 辅助编程中沉淀的六个核心洞见

经过一年多的日常实践，AI 辅助编程在我的工作流中从”辅助工具”演变成了”核心协作伙伴”。这个过程沉淀出了一些认知——它们不追求新奇，只追求准确。这篇文章记录的是截至 2026 年中，我个人认知框架中的六个核心洞见。

引言：认知的演化路径

过去一年半，我在 AI 辅助编程中的角色经历了三次转变：

工具使用阶段：把 AI 当成更聪明的搜索引擎和代码补全¹
流程重构阶段：围绕 AI 重新设计自己的工作流，从”写代码”转向”引导 AI 写代码”²
范式反思阶段：开始区分不同场景下 AI 的最佳使用模式，意识到”单人”和”多人”模式下 AI 的角色截然不同

这篇文章属于第三阶段的产物。它不是操作指南，而是一个仍在演进中的认知框架——关于 LLM 能力边界、协作模式选择，以及技术和人的关系。

洞见一：LLM 能力是地基，但上下文窗口同样关键

模型本身的能力决定了理解和生成的天花板——这是一个常识，但在实践中容易被低估。不同模型在同一任务上的表现差距是系统性的，prompt 工程能优化但无法跨越这个差距。

但真正影响日常工程体验的，还有另一个因素：稳定且足够长的上下文窗口。

一个在单项得分上略低但能稳定处理 200K token 上下文的模型，在跨项目重构场景中的实际体验，往往优于一个单项得分更高但上下文窗口受限的模型。原因在于：多项目重构的决策不是孤立的——修改包 A 的接口时，需要同时理解它在包 B、C、D 中的调用模式。只有能一次性消化这些关联代码，才能做出不”短视”的方案。

这涉及到 LLM 的一项基础能力——长上下文中的”注意力持久性”。相关研究表明，模型在长上下文中的信息检索和推理能力会随位置衰减³。稳定的大上下文窗口意味着这种衰减被控制在了可接受的范围内，使得跨文件的语义理解成为可能。

所以更准确的表述是：模型能力决定上限，上下文窗口决定这个上限在真实工程中能被兑现多少。

洞见二：Plan 的核心价值是理清人的思路

在 AI 辅助编程的讨论中，”Plan”经常被理解成”让 AI 按步骤执行”的手段。但我逐渐发现，Plan 的最大受益者不是 AI，而是人自己。

原因有两点：

第一，Plan 是外挂工作记忆。 复杂任务涉及大量上下文——文件依赖关系、接口契约、状态迁移路径。把这些结构化成 Plan 写在 prompt 里，相当于给思考过程加了一个”外挂存储区”。这与人脑的工作记忆限制有关——我们同时能追踪的信息量是有限的⁴，Plan 把这个限制放大了。

第二，Plan 是人和 AI 之间唯一的可追溯沟通证据。 在长对话中，AI 的行为可能因为上下文压缩、模型更新等因素产生漂移。一份结构化的 Plan 是判断”AI 是否偏离了原定方向”的锚点。当 AI 生成的代码和预期不符时，不是凭感觉重来，而是对照 Plan 指出”你在第 3 步偏离了方向”。这让调试协作过程变得可操作。

这个概念和 Chain-of-Thought Prompting⁵ 有相似之处——显式的推理步骤能显著降低模型在长上下文中的错误率。但 Plan 在工程中的意义不止于此：它从”推理工具”变成了 “通信协议” ，让人和 AI 共享一个可参照的路线图。

洞见三：Monorepo 让 AI 跨项目整体提交成为可能

这是实践中沉淀出的一个很具体的观察：单仓库（Monorepo）结构天然适合 AI 主导的跨项目修改。

Google 在 2016 年发表的论文中详细阐述了 Monorepo 的优势——统一的依赖管理、原子化的跨项目变更、简化的分支策略⁶。这些优势在传统开发中体现为”减少沟通成本”，在 AI 辅助开发中则体现为“让 AI 能看见全局”。

举个例子：当你修改一个共享库的接口时，在 Monorepo 中，AI 可以同时看到：

这个接口的定义（共享库中的源码）
所有调用方的使用模式（同一仓库中的其他项目）
对应的测试代码如何 mock 这个接口

然后 AI 可以一次性完成：修改接口定义 → 更新所有调用方 → 调整测试用例 → 验证编译通过。这个完整的原子提交在 Monorepo 中是一个自然的操作，在多仓库（Polyrepo）中则需要跨仓库协调，AI 目前难以胜任。

sequenceDiagram
    participant Human as 开发者
    participant AI as AI Agent
    participant Repo as Monorepo

    Human->>AI: 重构共享库接口
    AI->>Repo: 读取接口定义（包 A）
    AI->>Repo: 扫描所有调用方（包 B、C、D）
    AI->>Repo: 读取对应测试代码
    AI->>AI: 制定修改方案
    AI->>Repo: 修改接口定义
    AI->>Repo: 更新包 B 调用
    AI->>Repo: 更新包 C 调用
    AI->>Repo: 更新包 D 调用
    AI->>Repo: 调整测试用例
    AI->>Repo: 编译验证
    AI-->>Human: 提交完整变更

这个模式在多仓库环境下很难复制——AI 需要同时打开多个仓库、理解它们的依赖关系、协调跨仓库的提交顺序，目前的主流工具链对此支持有限。

洞见四：TAO 模式的关键在于可验证的闭环

“TAO”指的是 Task（任务分解）→ Action（执行）→ Observation（反馈观察） 的结构化提示范式。它并非一个全新的概念，与 ReAct（Reasoning + Acting）模式⁷有共同的理念基础——让 AI 不是一次性输出最终结果，而是在”思考 → 行动 → 观察结果”的循环中逐步逼近目标。

但在工程实践中，TAO 的关键不在于 T 和 A，而在于 O——Observation（观察）。

graph LR
    T["Task<br/>分解任务"] --> A["Action<br/>执行"]
    A --> O["Observation<br/>观察反馈"]
    O -->|"未达到预期"| T
    O -->|"达到预期"| D["Done<br/>完成"]

    style T fill:#87CEEB
    style A fill:#90EE90
    style O fill:#FFD700
    style D fill:#90EE90

为什么 O 是最关键的？因为没有 Observation 的闭环，TAO 就退化成了”让 AI 一步一步做”的简单链式调用，和普通的 prompt 没有本质区别。TAO 的真正价值在于让 AI 每一步的产出都被检验——检验结果反馈到下一步的任务分解中，形成一个可验证的闭环。

这和软件工程中的闭环反馈原则是一致的：每次修改都应该有对应的验证手段（测试、lint、类型检查），验证结果决定下一步方向。TAO 只是把这个原则应用到了和 AI 的协作过程中。

在单人高效模式下，这个闭环可以非常紧凑：AI 执行 → 人肉眼验证 → 反馈修正 → AI 再执行。但在多人场景下，这个闭环需要被编码为更正式的流程——代码评审、CI 门禁、契约检查——每一个都是 Observation 环节的工程化实现。

Observation 环节的数据基础设施

要让 Observation 真正可操作，需要建设一套覆盖 AI 全链路的数据基础设施。仅仅依赖”看 AI 的输出”是不够的——因为很多错误的根因不在最终输出，而在中间某个环节的状态。具体来说，需要关注以下数据源：

日志数据：AI 的每次输入输出、每次工具调用、每次决策路径都需要可追溯的结构化日志。这是最基础的观测手段——没有日志，无法定位 AI 行为异常的原因。这在之前的文章中曾作为”埋点驱动迭代”的核心组件展开过⁸。
数据库状态：AI 执行的变更会体现在数据库状态中。当 AI 操作涉及数据迁移、批处理任务或状态变更时，能查询和对比执行前后的数据库状态是定位问题的关键手段。
1:1 可复刻的测试环境：AI 行为与运行环境强相关——同一个 prompt 在不同依赖版本、不同数据分布下的输出可能不同。拥有一个可随时重建、与生产环境配置一致的测试环境，是隔离 AI 行为变量的前提。否则你无法判断”这次输出不对”是因为 prompt 有问题，还是因为环境中的数据状态与上次不同。
页面层的多模态可观测性：当 AI 的操作涉及用户界面时（无论是生成前端代码、模拟用户操作、还是验证 UI 行为），传统日志无法覆盖”视觉语义”层面的信息。需要组合使用 Playwright 等工具采集 UI 截图、通过 OCR 提取界面文本内容、再借助多模态大模型理解页面状态。这一层观测正在成为 AI 协作中不可或缺的一环——它能捕捉到”按钮没渲染出来”、”布局错位”等日志完全无法反映的问题。

从 TAO 到 Harness Engineering

当 Observation 环节从”人眼看一下”升级为上述这套数据基础设施时，TAO 模式就超越了 prompt 技巧的范畴，进入了工程化的层面。我把建设这套基础设施的实践称为 Harness Engineering——它关注的不是”怎么写 prompt”，而是”如何构建支撑 AI 稳定运行的工程体系”。

这套体系的关键组件包括：

可观测性管道：采集 AI 全链路的日志、状态、产出，形成可检索、可回溯的观测数据湖
可复现环境：保证 AI 的每次执行都在一致的上下文和数据状态下进行，行为偏差可归因
门禁系统：在 AI 的每个产出节点设置自动检查（类型校验、契约验证、测试覆盖）
回滚与补偿机制：当 AI 行为不符合预期时，能快速回滚并补偿受影响的下游

Harness Engineering 的核心思想是：不要依赖 AI 的可靠性，而要通过工程手段把 AI 的不可靠性控制在可接受的范围内。 这和传统软件工程中防御式编程的逻辑相通——你不能假设输入永远合法，所以用类型系统、契约测试、降级策略来兜底。Harness Engineering 就是对 AI 的”防御式工程”。

这套思路也与之前文章中讨论的”LLM 工程化的自举迭代框架”⁹一脉相承——两者都强调用系统能力而非人工干预来管理 AI 行为的不确定性。

洞见五：AI 拉平了技术壁垒，但拉不平决策与责任

AI 确实在拉平一些长期以来区分小团队和大团队的壁垒：

知识壁垒被拉平了——以前大团队才养得起专门研究 Monorepo、形式化验证、性能分析等领域的专家，现在小团队一个人 + AI 就能达到相当的高度
执行力差距被拉平了——大团队靠人多并行推进，但 AI 可以让小团队的单人具备”伪并行”能力（一个上午同时在多个方向上推进）
规范落地难度被拉平了——大团队靠制度强制统一风格，小团队靠 AI 自动遵循规范，甚至比人更一致

但”拉平”不等于”消失”。拉平的是技术实现层面的壁垒，拉不平的是三个更本质的东西：

维度	被拉平	没被拉平
知识	获取技术知识的速度	判断”该学什么、该信什么”
执行	编码实现的效率	决定”功能做不做、何时上线”
规范	代码风格的统一	架构决策的责任归属
质量	局部代码的正确性	长期维护成本和技术债务治理

技术壁垒的降低，反而让剩余竞争点——人的判断力——变得更加重要。 AI 可以写代码，但”这个接口要不要这样设计”、”这个依赖该不该升级”、”这个功能现在做还是以后做”——这些决策依赖的是人对业务逻辑、系统边界和长期成本的理解，不是 prompt 技巧。

这个观察和 Frederick Brooks 在《人月神话》中的观点有跨越时空的呼应：软件工程的本质困难不是”写代码”，而是”理解要写什么”¹⁰。AI 降低了”写”的成本，但”理解”的成本仍然由人承担。

洞见六：AI 作为执行者与辅助者的模式切换

这是所有认知中最根本的一个二分法。经过反复实践，我意识到 AI 和人协作存在两种截然不同的模式，它们对流程、信任和团队结构的要求完全不同：

维度	执行者模式（单人）	辅助者模式（团队）
AI 角色	自主规划、跨项目整体执行	代码补全、生成单测、解释代码
决策者	AI 出方案，人确认方向	人做所有决策
提交粒度	跨包原子的整体提交	按模块拆解的小粒度 MR
信任模型	人对 AI 的输出全盘审查	团队逐条归因、可追溯
适用团队	≤5 人，高度信任	大团队，传统流程
协作协议	Plan + TAO 闭环	规范文档 + 人工评审

这两种模式对技术能力、流程、信任机制的要求不仅不同，甚至互斥——在执行者模式下建立的自动化流程，在辅助者模式下会变成噪音和负担。

团队规模的约束不是偶然的。Robin Dunbar 在 1992 年的研究中提出了一个认知上限：人类的社交网络规模受限于新皮层容量，稳定协作的群体很难超过 150 人¹¹。虽然这个数字是针对原始社群的研究，但软件团队中的”认知开销”也有类似的规模效应——当团队超过一定规模（实践中大约是 7-8 人），成员之间需要记住的协作协议、响应预授权请求、理解变更影响报告的成本就会超过收益。

graph TD
    subgraph "执行者模式（≤5人）"
        A1["人定方向"] --> A2["AI 自主执行"]
        A2 --> A3["人审查结果"]
        A3 --> A1
    end

    subgraph "辅助者模式（大团队）"
        B1["人定方向"] --> B2["人写需求/设计"]
        B2 --> B3["AI 局部辅助"]
        B3 --> B4["人工评审/集成"]
        B4 --> B1
    end

    style A1 fill:#90EE90
    style A2 fill:#87CEEB
    style A3 fill:#FFD700
    style B1 fill:#90EE90
    style B2 fill:#FFD700
    style B3 fill:#87CEEB
    style B4 fill:#FFD700

这两种模式之间的切换成本，是很多关于 AI 生产力的讨论中被忽略的因素。单人场景下的高效模式（AI 接管、整体提交）一旦进入多人场景，就必须切换回更传统的辅助模式，而之前建立的那套自动化流程并不能平滑迁移。

没有银弹：认知闭环的终点

Fred Brooks 在 1986 年的经典文章《No Silver Bullet》中提出，软件工程中没有能够”在一个数量级上提升生产率”的单一技术突破¹²。这个判断在近四十年后被重新审视——LLM 带来的变化可能确实超出了 Brooks 当年的预测框架。但 Brooks 的另一句话在今天依然成立：软件的本质困难在于”概念结构”的复杂性，而不是”实现”的复杂性。

AI 解决了实现层面的复杂性，但概念结构的复杂性——需要做什么、为什么这么做、什么时候不做——仍然需要人的判断。

这六个洞见最终指向同一个结论：AI 不会消除软件工程的困难，它只是把这些困难重新分配到不同的位置。 知识壁垒被拉平了，决策质量的门槛变高了；写代码变快了，但搞清楚”该写什么”变得更关键了。人和 AI 之间没有最优的协作模式，只有最适合当前场景的协作模式。

没有银弹，但有清晰的认知框架——这就够了。

References

一年多的实践总结：参见《One Year of AI-Assisted Programming: Insights, Practices, and Reflections》，2026-01-31。记录了从 AI 工具使用者到深度融入日常开发工作流的认知演化。 ↩
角色转变的框架性论述：参见《AI Reshaping Software Development Workflow: From Code Writer to AI Conductor》，2026-02-10。提出了从”代码写手”到”AI 指挥”的角色转换模型。 ↩
长上下文中注意力衰减的研究：Liu, N. F. et al., Lost in the Middle: How Language Models Use Long Contexts, arXiv:2307.03172, 2023。研究发现模型在长上下文中的信息检索能力随信息位置而显著变化——位于中间位置的信息被有效利用的概率最低。https://arxiv.org/abs/2307.03172 ↩
工作记忆容量的经典研究：Miller, G. A., The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review, 63(2): 81–97, 1956。提出了人类工作记忆同时处理信息量的有限性，是理解”Plan 作为外挂存储”重要性的认知心理学基础。https://doi.org/10.1037/h0043158 ↩
Chain-of-Thought Prompting：Wei, J. et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, NeurIPS 2022。提出在 prompt 中加入显式的推理步骤链能显著提升 LLM 在复杂推理任务上的表现。https://arxiv.org/abs/2201.11903 ↩
Google 的 Monorepo 实践：Potvin, R. & Levenberg, J., Why Google Stores Billions of Lines of Code in a Single Repository, Communications of the ACM, 59(7): 78–87, 2016。详细阐述了 Google 在单一仓库中管理数十亿行代码的经验、工具链和工程实践。https://doi.org/10.1145/2854146 ↩
ReAct 模式：Yao, S. et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023。提出在 LLM 中交错进行推理轨迹（Reasoning）和动作步骤（Acting），让模型在”思考 → 行动 → 观察结果”的循环中完成任务。TAO 模式在思路上与之相通，强调了观察反馈在闭环中的核心地位。https://arxiv.org/abs/2210.03629 ↩
埋点数据驱动迭代的工程实践：参见《大模型工程化的自举迭代框架：从 Demo 到可持续生产系统的五层实践》，2026-05-04。其中的”埋点驱动迭代”和”强类型驯服 LLM 不确定性”两节详细讨论了全链路日志采集和 schema 校验的工程方案。 ↩
自举迭代框架的整体论述：同上。该文提出的五层实践（流程固化、tmux 运行时、Compact 卡点解法、埋点驱动迭代、强类型驯服 LLM）构成了 Harness Engineering 在当前阶段的工程原型。 ↩
Brooks, F. P., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975（第二版 1995）。提出了 Brooks’ Law：”向一个已经延期的项目增加人手，只会让它更延期。” 本文引用的是其中关于软件工程本质困难（essential complexity）和附带困难（accidental complexity）区分的论述。 ↩
Dunbar, R. I. M., Neocortex size as a constraint on group size in primates, Journal of Human Evolution, 22(6): 469–493, 1992。提出了著名”邓巴数”——灵长类动物的新皮层体积限制了其社交网络规模，对人类而言这个上限约为 150 人。稳定协作的小团体（如狩猎采集群体）通常在 30-50 人，核心信任圈约 5-15 人。 ↩
Brooks, F. P., No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 20(4): 10–19, 1987。提出了软件工程中”本质困难”（概念结构、规格、设计的复杂性）和”附带困难”（编程语言、工具、平台的限制）的区分，并断言没有单一技术能在一个数量级上提升软件开发的生产率。 ↩

阿男聊技术 / Published on Jun 09, 2026

上一篇 Linux hrtimer 纳秒精度从何而来：从 TSC 到红黑树的完整链路