AI助我，我注AI——AI Coding的道法术器

2026年03月15日

一道：AI指挥官10x效率提升的可能性
二法：AI的能力边界与失效模式
三术：从Agentic Coding到Harness Engineering
四器：数字化转型：工作中的应用

一道：AI 指挥官10x效率提升的可能性
二法：AI的能力边界与失效模式
三术：从Agentic Coding到Harness Engineering
四器：数字化转型：工作中的应用

一道：AI 指挥官10x效率提升的可能性

1.1 知识平权 ≠ 决策平权

在2024年大家还在观望AI什么时候会变得更智能一些，2025年AI已经普及到各行各业。2025年AI的慢思考能力，已经让AI能够达到各行各业博士的水平。解决一个问题，已经不需要从0到1了解整个知识体系了，只需要根据自己的情况，定制型问答即可。
在互联网做业务，因为为了保证24小时响应，所以大家需要轮流晚上值班。难免会经历半夜被电话吵醒的经历。面对半夜被吵醒而失眠这个问题，应该怎么办？
2年之前，这种问题只能去看医生，或自己读书寻找答案。
如果去看医生，医生听到你仅仅是因为值班，偶尔失眠。可能都懒得回答你的问题，3分钟就把你打发走了。
如果如果自己探究答案，需要自己看几本书，系统性的了解睡眠认知疗法。需要尝试一些通用的方法，探索具体哪些方法更适合自己。仅仅是阅读几本书，熟悉整个体系，这也是不太小的成本。
在知识平权时代，AI就是有博士级别的私人助手，他能根据你的情况，针对性的做出建议。
对于工作中占据很重要席位的Coding，AI已经非常擅长了。那么AI在团队中应该占据什么样的位置呢？

1.2 AI 与实习生的根本区别：责任

如果把公司的组织架构简化成四层：头部管理者，腰部管理者，腿部管理者，一线员工。那么，AI属于哪一层？
按照2025年5月红杉资本闭门会的预测，未来会出现一人独角兽公司。有了大量Agent，都由一个人负责，然后交付结果。显而易见，每个人都可以用AI，按照正常的思路来，其实就是再最下面一层。一个人可以带一个团队。
用了两年AI Coding之后，我发现其实并非这么简单。

AI不承担后果，所以不拥有责任绑定的决策权。

其实一个小项目，交给应届生，甚至是一些比较厉害的实习生来做，他其实是能够完全做完的，中间可能会有沟通，但是他会全部做完，并且负责人的。
但是AI在团队中的位置是执行层、放大器，并不担负责任。谁做决策，谁负责任。
AI与人不一样的地方，就在于AI不负责任。责任和决策是相互绑定的，不负责任，就不能做决策。
而且最近两年用了大量的AI，尝试做了大量的项目，有过大量高效的经历，也有失败的经历，因为没有及时git提交，导致大量写好的代码又丢失，而且无法恢复。
最终现在的理解就是：人要在其中做大量微决策。要完全主导，而不是完全交给AI来做。

1.3 Vibe Coding并非不懂编程

氛围编程”（Vibe Coding），它入选了2025英国柯林斯词典年度词汇。
因为AI Coding的飞速发展，流行很多vibe coding相关的产品与公司，其实Vibe Coding的初衷，是提高工程师的开发效率。
但是有些产品企图让用户用几句话，就能构建出一款产品。这种方向的想法是美好的，这迎合人类大脑喜欢简单事情的特点。但是几句话描述仅仅是开始，并非结束。如果是一个简单的，只有页面展示的产品，那确实可以快速生成。但是如果有复杂的逻辑。那这对产品选型、交互、技术架构、可维护性，都有很高的要求。不懂编程就Vibe coding，只会带来大量的技术债务。
对于复杂的项目，有很多都是需要做决策，而做决策需要避免能力的空心化。资深工程师之所以能看出来架构的好坏，是因为他经验丰富，有过各种被坑的经验。
比如以下决策，是需要有技术背景的，如果因为不懂而做错了决策，那么后期将会有很大的维护与拓展成本。
1 使用DDD架构的Domain Layer（领域层）来存放共同的业务规则、领域模型、业务逻辑，适配多Target。
2 Domain和主工程，两个仓库并列关系，两个独立的git管理。gitignore的配置。
3 性能类，Canvas与Metal/SceneKit的选择。前期需要通过依赖反转，在Infrastructure层定义渲染接口，上层定义抽象，下层实现细节，就可以再不改变业务逻辑的情况下更换业务引擎。既减少了维护成本，又避免带来巨大的因耦合造成的回归工作量。否则后期想要替换成Metal就会有很大的迁移成本。
4 交互类关于Ritual节奏，Haptic触觉反馈的选型；
5 依赖注入，减少组件间的耦合。
AI不负责、不判断、不承担后果。所以人必须成为”持续做微决策的AI指挥官“。
（引出下一章的问题）其实责任是一方面影响因素，还有另外一个影响因素，就是AI无法保证100%正确。

1.4 如何设计时间不对称的工作流，拥有AI时代的杠杆

以前文档是代码的指南，代码才是真理。产品的一个需求，到了实际上线，效果可能就打折扣了。不得不因为时间有限而妥协。
现在权利发生了翻转。不再是文档服务于代码，而是代码服务于规范。

维护软件的核心：已经从修改代码 -> 演进规范。
调试bug的核心：修复错误代码 -> 修正产生错误代码的规范或方案
技术重构的核心：大规模迁移代码 -> 基于同一份规范，生成一个全新技术栈的实现。

比如，每天都会提交git，拉分支。这些过程是怎么操作的。5年前是否就是这样操作的？5年内没有更新技术了？
2022年有几个月都是居家办公，当时每天都要打开vpn，输密码。这半分钟其实是无意义的操作，那这每天半分钟，如何优化？基于当时的技术应该如何解决，现在基于AI技术可以如何优化？
虽然每一个节点都是简单的操作，但是重构工作流就是这样，不可能一次全部优化更新，但是可以从一部分开始，逐步优化。最终将整体链路打通。

1.5 10x超级个体，为什么不能带来组织10倍效率提升？

从个人角度来看，如何设计时间不对称的工作流，就能拥有 AI 时代的杠杆。但是对企业来说，个人效率即使提升10倍，依然不能带来组织层面的整体效率飞跃。
一方面是因为整条业务链路，并不能完全自动化。还是需要涉及人的确认。
另一方面，是因为个人在整条链路中，不能做决策。
这其实是基于目前基于18世纪亚当斯密的《国富论》的底层原理：想要提高组织效率，就需要分工细化。每个人做其中的一个螺丝钉，这样能保持组织效率极其高。
但是这也会有另外一个问题，在AI时代更成为了瓶颈，即自己只能决策自己的一部分。比如整条业务链路，从产品、交互、研发、风控、策略、测试。一名研发，不能为产品做决策，遇到交互问题，还是需要请产品、交互同学来做决策。那这就阻断了整条自动化流程。
于是就有企业尝试横向发展，即全栈工程师，一名研发做前端、后端，甚至加上测试。再后期可能朝着产品、交互发展。
这是横向发展的思路。但是这也有一个问题，就是每个人的认知是有上限的。比如本文配套对应的PPT，是用AI做的，可以看到其界面比较酷炫，给我一个星期，甚至一个月的时间，我能做出来么？显然做不出来，因为我完全不懂设计审美。这不是时间的问题，而是根本不擅长做这一方面。
所以另外还有纵向发展的思路，即一个人深入钻研某一个方向，将这一个防线的效率提高10倍。比如一个方向一个小组有10个人，同时做5个项目。即每个项目需要2个人。那么朝着单个方向效率的提升，是否可以一个人代替6个人，同时做3个项目呢？
当然无论是横向，还是纵向发展，其实都是需要简单的链接。
平时做需求的时候，如果对于某一个功能，研发层面就涉及到很多个团队：FE、客户端、API、风控、策略。
就很容易出现技术方案遗漏、功能影响面评估不全面。那其实是因为很少有人能够了解整条业务链路。每个人都是深耕自己的一个方面。所以其实不仅是AI时代，在任何时代。都要求对不同方面的知识体系，能够进行链接。了解整体链路。

二法：AI的能力边界与失效模式

在2024年多模态大模型刚发布的时候，可以看到AI能够在文字、图像、视频领域都有一定的理解能力，但是还是会存在出错的情况。2025年其准确度已经得到了很大提升，最起码部分场景的编程领域，其速度与准确度已经超过大部分研发工程师了。那么随着技术的发展，2026年，甚至2027年，AI是否能够达到完美、不会出错的程度呢？

2.1 预测模型

AI是生成式模型，即基于概率进行预测。其天生就是生成相对准确的内容，而非绝对正确的内容。所以，基于目前的技术架构来看，AI永远不会达到100%正确的程度。

无法避免的幻觉
AI 最危险的不是“答不上来”，而是“答得太像真的”。AI 常见的2种失效模式

1 编造型（Hallucination），表现：非常自信
编论文
编 API
编法律条款
编不存在的概念
2 上下文漂移

多轮对话后，前提被悄悄改掉。
回答开始偏离最初目标。

2.2 类似快思考 / 慢思考的行为模式

诺贝尔经济奖得主丹尼尔·卡尼曼《快与慢》，提出了人有快、慢思考，快思考是不经思索，快速反应，比如开车的时候看到前车刹车灯亮了，这个时候不用思考，直接就会踩刹车。
因为LLM是按照概率预测，其实其类似快思考这种行为模式。但是通过强化学习，AI开始有了类似人类慢思考的过程。
LLM（大语言模型）的训练分为预训练，后训练。

后训练包括：
SFT（微调，指令学习）
偏好对齐（RLHF / RLAIF / DPO），强化学习
安全对齐（Safety）
能力注入（Tool / Agent / Function）
通过强化学习，AI有了涌现的能力，开始出现类似人类慢思考的能力。

2.3 Scaling Law缩放定律

CPU的发展遵循摩尔定律，即每18个月性能翻一倍。其瓶颈是芯片制程。CPU是串行操作，线性依赖，后一步的计算必须等待前一步的结果。
2020年《Scaling Laws for Neural Language Models》这篇论文，提出了AI

有清晰可预测进步。所以2022年就有4名学生辍学创办了Cursor，虽然在2022，甚至2023年，AI Coding都是笑话，但是按照当时的可发展速度的预测，他们坚信这个方向是对的。没过几年，25岁年收入就达到数亿美金。
2024年6月Stable Difussion3开源，当时就爆发了电商订单的需求，不过当时还是有一些电商门槛的。

2025年10月，Gemini Banana发布，这为图书故事需求爆发提供了技术可行性。经过一个月验证，发现可以工业化批量出图，于是相关公司就爆单了，提前做好准备的公司，接单接到手软。如果没有提前做好准备，机会来临时候再准备显卡，机器，肯定是来不及的。
AI删除你的代码，你还用不用？
2024年6月，分享了《AI站在颠覆世界的前夜》，当时用AI Coding，看似编程就是笑话，为什么还要用？因为只要相信这是必然，一定会越来越好的。只要做，就能提前了解、熟悉这个流程，提前准备好，等待机会的来临。
2025年的时候，有一次Coding一天，到晚上的时候让AI写新功能，结果把我今天改的全删除了。那种心情，你懂得。。。

其实长期不提交代码，不是个好习惯。之前身边就有两个同事，因为长期不提交代码而导致损失的。一次是同事电脑突然坏了，结果几个星期的代码都没了。另外一个是有个同事突然消失了七天，他代码也没有提交。而测试、上线又比较紧张，所以我又帮忙从0全部写了一遍。在那之后我有个习惯是每天提交一次代码。现在有了AI，不得不改变习惯：每个小改动，每一次commit，都需要push一次。
很多事情，你必须要提前准备，否则等到机会来的时候，你根本用不了。

比如底层技术，很多底层技术，招聘的时候也会关注，为什么工作的时候，都是CRUD，简单的工作，还是需要了解底层技术呢？一方面这是对学习能力的一种考验，另外就是需要的时候再学、来不及，必须提前储备。

2.4 仅仅LLM强大不够，还需要工具

根据缩放定律，LLM一直在发展，但是其通常仅仅是文本的预测，对于我们实际工作流的重构，还是有比较大的困难。因为我们很多工作，都是在很多个软件之间来回切换。虽然大部分内容很简单，只是图像看一看，鼠标点一点，键盘按一按，但是对AI并不简单。
对人很简单，但是对AI来说很困难的操作

鼠标点一点
键盘按一按
Coding：Cmd + shift +F全局搜索，编译等功能
所以AI通过MCP的方式，来达到间接使用工具的方式。通过Bash来使用rag，awk, sed, grep等命令。

AI了解代码的方法
Bash：awk , sed, grep, find, ls, cd, head, search(pattern:)

MCP，通用工具插口：操作文件系统、IDE、浏览器、数据库、桌面GUI、Bash/PowerShell
LSP
Bash命令进行全局扫描，会当成长文本理解，噪声太多。去年又出现了LSP，解析代码形成AST，能更精确的定位方法的声明，调用链。并且不用再全局搜索，减少token的消耗。也不会因为猜测方法调用，而导致编译出错。

三术：从Agentic Coding到Harness Engineering

3.1 AI范式的发展阶段

Step1 2024年，AI辅助编程：tab代码补全，搜索引擎。
从2022年到2024年，AI IDE只能补全代码。
Step2 Vibe Coding
凭氛围、感觉编程。适合做一个小demo。
代码不可维护；玩具级，技术债制造机。
Step 3 Agentic Coding
2025年5月opus4.0的出现，让编程能力有了巨大的提升，AI完成一个模块、甚至一个需求不成问题。
2025年11月opus4.5出现，模型能力的提升是一方面，关键是价格从每百万75刀，降到了25刀。这就成为大众能接受的价格了。刚发布的两周，还能享受和Sonnet同样的价格，更便宜的15刀。
12月Skills正式发布标准，这让可复用的技能成为通用标准，无论是通过人调用Slash Command，还是AI根据场景，渐进式加载Skills，都让AI更具智能与自主性。
Step 4 Harness Engineering
2025年底，有Spec Kit, OpenSpec等SSD（Spec-driven development），通过规范化的文档约束AI自由发挥。 2026年2月OpenAI提出了新的概念：Humans steer, Agents execute。人类掌舵，AI 执行。通过约束环境、自动化验证和反馈闭环。等这一套流程实现了之后，整个开发流程效率会极大提高。要么不需要那么多研发参与，要么就大量创新，探索更多新产品。
3.2 AI Coding IDE的交互方式
2024年的AI IDE，仅仅是智能补全，代码解释，写几个简单的函数。那个时候还是GUI的形式。基于VS Code fork的GUI IDE，强调交互式编辑和Agent模式。因为AI还仅仅是辅助，不能脱离人独立完成一个项目。当时称之为Agent，可以调用若干工具。随后又出现了Agentic，形容词，指的是AI系统具有代理性。即能够自主决策、规划、行动并实现特定目标，而需要最小的人类监督。这区别于传统的生成式AI，仅响应查询。Agentic AI强调自治和多步问题解决能力。
既然无需人为参与，2025年开始，GUI开始向CLI过度。Agent coding 升级为Agentic coding，即大量自动化的工作流。Agentic CLI聚焦于“自治”和“脚本化”，强调后台运行，并行任务，让AI像人类工程师一样操作。
包括但不局限于以下功能：
Spec-Driven Workflow：用规格(Specs)定义需求、设计和任务，然后AI自动规划和执行。
Plan / Edit分离。Plan生成详细计划任务(roadmap，任务分解），Edit/Agent模式自主执行（多文件编辑，测试运行）。
工具集成：代码库搜索，终端执行，自定义技能（SKILL.md）和命令（/commands）。
CLI扩展，支持终端中的agentic操作，进一步强化其agentic属性。
Autonomous Agents。独立处理任务，多仓库变更、测试运行，PR创建。
Agent Hooks：事件触发自动化（文件保存时更新测试），支持后台运行和多代理写作。

CLI集成：支持终端中的agents，构建features、自动化workflows，甚至SSH操作。
在Claude Code开始执行的时候，因为其自主性很强，我们也不知道AI在干什么，不过我们会发现有很多状态显示，似乎是以幽默的方式展示AI正在自主工作。

状态 (Status)	字面含义与幽默解读
Quantumizing	量子化中听起来很高科技、很科幻。暗示 Claude 正在动用“量子大脑”进行极其复杂的计算（其实就是在算你的代码）。 
Razzle-dazzling	炫目表演中 / 令人眼花缭乱源自“Razzle Dazzle”，指令人眼花缭乱的表演或排场。暗示 Claude 正在准备给你展示一个“惊艳”的结果。   
Ruminating	沉思中 / 反刍原意指动物（如牛）反刍食物，引申为“反复思考”、“深思熟虑”。暗示 AI 正在仔细琢磨你的需求。   
Scurrying	急促奔跑中形容小动物（如老鼠、松鼠）急匆匆地小碎步跑。画面感是 Claude 正在后台手忙脚乱地为你跑腿、找文件。   
Simmering	慢炖中 / 酝酿中烹饪术语，指用文火慢炖。暗示想法正在“锅”里煮着，还需要一点时间才能入味（生成完成）。
Tomfoolering	搞怪中 / 耍宝源自“Tomfoolery”，指愚蠢或顽皮的行为。这是最明显的幽默文案，暗示 AI 正在后台“调皮”一下（其实还是在干活）。
Wandering	漫游中 / 闲逛暗示 AI 的思绪正在代码库或知识库中四处游荡，寻找灵感或答案。   
Working	工作中这是最正常、最朴实的状态。

3.3 Prompt

Prompt是我们与AI沟通的最基本的语言。通过熟悉不同类型的Prompt，来进一步了解AI。

1 基础提示类型Prompt

Zero-shot（零样本， Direct）
Few-shot（少样本）
2 推理增强类型Prompt
Prompt Chaining
COT (Chain of Thought，思维链)
Self-Consistency
Tree of Thoughts（ToT）
图片链接
https://www.promptingguide.ai/_next/image?url=%2F_next%2Fstatic%2Fmedia%2FTOT.3b13bc5e.png&w=3840&q=75
Prompt Chaining（提示链），它将复杂任务拆解为多个子任务，上一个 Prompt 的输出直接作为下一个 Prompt 的输入，非常适合长文本处理或复杂的流水线（Pipeline）工作。
COT (Chain of Thought - 思维链)，让AI一步一步思考，但是有一个缺点：采用贪婪解码生成唯一推理路径，这种方式容易因某一步骤的错误导致整体答案错误。通过Self-Consistency，多人投票的机制，可以避免某一步出错。
Self-Consistency（自洽性），旨在改进COT提示的效果。通过生成多条不同的推理路径，最终选择出现频率最高的答案作为结果，从而避免单一路径可能出现的错误。解决大模型“幻觉”和提高数学/代码逻辑准确率的最有效手段之一。本质就是“多人表决”。
Tree of Thoughts (ToT，思维树)，允许模型探索多条分支路径，并且可以结合启发式评估（如自我打分），在遇到死胡同时“回溯（Backtracking）”。像树的分支一样，每个节点都有不同方案的决策。像树状分支一样探索。

3 知识增强类型Prompt

Generated Knowledge Prompting
RAG（Retrieval-Augmented Generation）

Generated Knowledge Prompting，模型自己生成知识再回答。
RAG（Retrieval-Augmented Generation），通过外部检索真实知识再回答，更可靠。

4 工程化类型Prompt

ReAct (Reasoning and Acting - 推理与行动)
目前 Agent开发最核心的 Prompt 框架。它要求模型在思考和行动之间交替进行，并根据行动的观察结果（Observation）决定下一步。适用需要让 AI 自己上网搜索、查数据库、执行代码的场景。
Step-Back Prompting (后退提示)
遇到复杂问题时，提示模型先“退后一步”，提出一个更宏观、更底层的原理性问题，解答完原理后，再回头解决具体问题。比如在开发魔方算法的时候，请说明其坐标系与贴片跟踪的最基本的设定。
联想一下工作中，有时候遇到比较复杂的问题，如果无法解决的时候，就要退一步，从更宽的视角与维度，从研究这一类问题的思路开始，这个时候可能就能解决了。比如之前分享的《黑盒下的逆向分析：利用 nm 与 Hopper 定位 Incode SDK 符号覆盖问题》，这就是一个无解的问题，通过研究更底层的原理，则可能有更有效的解决方案。
Graph of Thoughts (GoT，思维图)
ToT（思维树）的升级版。思维树只能分支和回溯，而 GoT 允许将不同的推理分支合并（Merge）起来。比如同时生成了三个魔方复原的思路，GoT 可以提取这三个思路的优点，组合成一个最终的完美方案。
Directional Stimulus Prompting (方向性刺激提示)
不直接给模型一堆少样本例子，而是给它一些线索或关键词，强制引导它按照特定方向生成内容。这在做特定格式的文本摘要时非常有用。
联想一下实际的工作，有时候我们得到的其实不是具体的工作内容，而是一些思路、方向。具体实施还是需要我们进一步具体化。

为什么公司推荐用Claude Code IDE呢，其实是因为其内置提示词做的比较好。降低了用户使用Prompt的成本，但是并不是说Prompt不重要，而是从显示技巧，变成了隐式能力+系统设计。特别是作为Agent的设计者，更需要这一项技能。

3.4 MCP

MCP有三种能力：

Tools（工具）：AI 可以主动调用的函数，比如浏览网站、读文件。
Resources（资源）：只读的上下文数据源，比如项目文件列表、数据库 schema。AI 可以读取但不能修改。
Prompts（提示词模板）：预设的交互模板，比如代码审查流程。
推荐比较好用的MCP：

Chrome DevTools MCP: 操控浏览器进行页面调试、网络分析和自动化检查
Figma MCP / mastergo: 读取和修改 Figma 设计稿以实现设计到代码的自动化
Context7 MCP / Ref MCP: 官方实时文档，只提供检索，比较安全。
Filesystem: 提供读取权限的文件系统接口。
Replicate MCP: 调用图片生成接口，可用于生成配图
Semgrep MCP: 对代码进行静态安全扫描和规则检测
MCP SDK: 用于开发和接入自定义 MCP 工具的官方开发包
GitHub MCP: 直接操作访问代码仓库、PR、Issue 和 CI 流程
Stripe MCP: 自动化创建和管理支付、订阅及 Webhook
ShadCN MCP: 生成可直接使用的 React + Tailwind UI 组件
Vercel MCP: 自动部署前端应用并生成预览环境
EdgeOne Pages MCP: 提供国内友好的前端静态站点托管与发布
Cloudflare MCP: 管理边缘计算资源如 Workers、KV 和 R2
Neon MCP: 按需创建和管理 Serverless PostgreSQL 数据库
Supabase MCP: 集成认证、数据库、存储和实时能力的一体化后端服务

3.5 SKILL

推荐网站：https://skillsmp.com/
Skills一方面解决上下文的问题。以前只有Rule，如果全部加载，则会导致上下文有一部分噪音，并且占用了若干上下文。具体实现就是渐进式加载的思路。
另一方面可以解决技能复用的问题，对于一些重复的固定的流程，可以通过SKILL标准化。比如以下几个可以复用的SKILL流程。

代码安全扫描

接入大模型的仓库，需要签名敏感文件，后缀包括：.keystore、.jks、.p12、.pfx、.cer、.mobileprovision。
这种就可以写一个Skill，包括扫描描述，使用的脚本文件（包括固定的输出格式）。
这样整个团队都可以复用，输出统一的扫描结果。

提交代码

Conventional Commits规范。通过Skill，既规范又高效。

修复编译问题

xcodebuild。在有些语言没有LSP的情况下，AI总是不能精确调用方法，可以通过编译让AI修复调用错误的问题。

修复bug的流程

复现步骤
怀疑范围
报错日志
问题根因
通过Skill固定的流程，避免AI瞎猜
解决复杂问题的思路
打印日志
拆分最小可测单元
对比
对于一个复杂算法，一直解决不了。AI会陷入到循环当中无法自拔，其实和人类似。有三种方法，可以让AI也试一试：
1 打日志，看数据流转的流程。否则AI也只是猜bug在哪里。特别是在代码量巨大的时候，打印日志是一种很好的判断数据流转的方法。
2 拆分最小可测试单元。将复杂的功能，拆分成小功能，一步步进行验证。
3 对比。如果是代码迁移，有另外一种编程语言可以对比，那么其实可以通过对比，让其拆分之后，进行一步步的对比。
AI在解决问题的时候，和人类似，如果在解决一个问题的时候，又引入了第二个、第三个问题，则会使用到诊断决策树。
3.6 Hook
Hook 事件非常多，根据触发时机不同，用法也很灵活。
1 UserPromptSubmit，每次发送消息时，自动注入上下文。
2 TaskCompleted，编译检测，自动记录到错误日志。当积累日志次数超过3次，自动更新Rule。硬编码检测也可以放在这里。
另外也可以再工具调用的时候触发Hook，调用工具包括：
MCP工具的调用，比如查询数据库的时候。
内置工具的调用，Bash等命令。
具体的声明周期参考：
https://code.claude.com/docs/zh-CN/hooks
https://www.runoob.com/claude-code/claude-code-hooks.html
3.7 SubAgent
当AI自主运行的时候，他需要完成很多项任务：熟悉代码，明确需求，技术方案设计，开发，测试。如果一个AI同时完成这么多任务，就很容易导致上下文爆炸，并且容易相互干扰。
类似于一个人工作一样，如果既干产品、又干交互，再加上开发、测试，不是不能干，而是效率不高，也容易搞混淆。所以最好的办法就是分工细化，职责分离。
而Agent也可以分成很多个subAgent。2026年初Kimi 2.5发布的时候，其宣传口号就有”100个subagent同时运行”。
不过一般也不需要那么多subAgent，Claude内置的有

Explore：只读权限，用于搜索和理解代码，使用速度快、成本低的模型（如 Haiku）。只读权限：grep, ls, read_file, find。
Plan：用于在写代码前进行复杂的步骤拆解和架构思考，不需要Bash权限，主要是思维连工具。
General-purpose (通用)：处理一些不需要特定权限的通用任务。具有读写权限，需要写代码。
另外自己也可以设置一些subagent：

Code Review Agent：专注于代码审查，分析代码库、检查标准（如 bug、安全性），使用技能指定审查流程。向主代理汇报建议。
Explore Agent（或类似Repository Analysis Agent）：探索代码仓库结构、下载文件、初步分析。常用于编码或研究任务。
Documentation Analysis Agent：分析文档，提取信息。
Web Research Agent：通过Web搜索收集文章、视频、社区内容。
Data Analysis Agent：结合技能处理Excel/PowerPoint等数据工作流。
Content Creation Agent：用于生成营销内容或其他创作任务。

多subAgent 是为了分治，为了让主大脑保持清醒，而不是为了快。其缺点就是token消耗过快。类似于一个项目三个人做，虽然比一个人做拆分的更细了，但是也会有更多额外的沟通成本。

3.8 Harness Engineering

Plan/Edit模式

通过cmd + shift + p 可以切换模式。对于简单的需求，可以直接使用Edit Mode来完成任务，对于复杂的任务，可以用Plan Mode，先做技术方案，再执行。
但是即使是Plan模式，其代码也可能放飞自我。并且其文档记录不固定。在使用SSD之前，想要找之前的记录比较困难。总结了不同AI IDE记录的位置。

AI IDE临时记录的文档

临时项目文件
~/.c/projects/userName/workspace/abc123.jsonl
计划文件夹
~/.c/plans/temporal-wondering-cake.md
~/.ide/plans/serene-munching-falcon.md
~/.KIDE/steer/spec
~/./antig/brain
通过加后缀标记完成
~/.g/a/brain/78df/walkthrough.md.resolved
随后就有了SDD。

Spec Kit，类似于PM+架构+RD。Spec Driven Development
OpenSpec，Change-Driven Development，基于改动而创建文档。每一个需求都认为是一个改动，都有详细的记录。
但是openSpec也对specKit作出了评价：

“vs. Spec Kit (GitHub) — Thorough but heavyweight. Rigid phase gates, lots of Markdown, Python setup.”
对比 Spec Kit：非常全面但太笨重了。有死板的阶段门槛，一大堆 Markdown 文件，还需要配置 Python 环境。而我们 OpenSpec 更轻量，允许你自由迭代。
不过他们都是关注的交付的标准。
Claude官方也推出了类似的，Superpowers，其更关注做事的过程
TDD：红-绿-重构（先写失败测试 → 实现 → 重构）。
调试：四阶段法（根因调查 → 模式分析 → 假设验证 → 修复），三次修复失败后自动触发架构审查。
脑暴：用苏格拉底式提问先把需求/设计彻底想清楚，再开始编码。
Harness Engineering
今年2月又提出了：Humans steer, Agents execute。人类掌舵，AI 执行。这进一步增加约束，让人完全从开发中释放出来。

3.9 规范记忆层级

不同AI IDE，其路径都不一样。Codex曾经呼吁统一路径到~/.agent，但是CC至今还未给出响应。
如果更新迭代之后来回切换，需要拷贝skills、rules，或者通过cc switch来切换。

Skills不同的路径

~/.agent/skills/ (理想的，以后可以统一的目录)
~/.claude/skills/skill-name/
~/.codex/skills/skill-name/
~/.gemini/antigravity/skills/skill-name/
比如实际的几个skills name以及其路径
~/.c/skills/fix-compile-error
~/.cu/skills/git-commit
~/.g/a/skills/repo-dir-list
~/.co/skills

Rule文件夹不同的路径

~/.cx/AGENT.md
~/.cc/rules.md；
~/.gemini/GEMINI.md
对于拆分的rule，可以拆分放到/rule文件夹中
~/.cc/rule/code-style.md
~/.cc/rule/i18nCashLoan
~/.cc/rule/i18nCreditCard
~/.cc/rule/UIListViewRule

另外还有覆盖关系，个人的配置是在~/.c/skills/；
项目的配置是在/.c/skills，其优先级要大于个人配置。团队项目的可以通过git提交。

3.10 权限控制

第一次使用AI IDE的时候，会有相关的权限提示

Bash command                                                        ctrl+e to explain
 Do you want to proceed?
 ❯ 1. Yes
  2.Yes, and don't ask again for similar commands in /Users/kqy/Desktop/code/project/cashloan
   3. No

多次给与权限之后，可以看到配置文件中有允许，也有拒绝。根据安全合规的要求进行设置。保持权限在一个平衡点，给的太多，容易误删文件，给的太少，又不够自动化。

// .cc/settings.json 
{
  "permissions": {
    "allow": [
      "read(./src/**)",                     // 仅允许读取src目录
      "write(./src/**)",                    // 仅允许编辑src目录
      "bash(npm run dev,./)",               // 仅在当前目录运行dev命令
      "bash(git status,./)"                 // 仅在当前目录查看git状态
    ],
    "deny": [                     // 绝对禁止的操作
      "bash(rm -rf *)",           // 禁止所有删除递归命令
      "bash(sudo *)",             // 禁止所有提权操作
      "read(./.env*)",            // 禁止读取所有.env相关文件
      "read(./.ssh/**)"           // 禁止读取SSH密钥
    ]
  }
}

3.11 不同 AI IDE 与 Model 的选择

AI Coding分两步

选择IDE

选择模型

厂家，AI IDE，Model对比
Anthropic，Claude Code，Opus Sonnet
Open Code, CLI，API
Google，Antigravity，Gemini Claude Opus/Sonnet 4.6 GPT-OSS 120B
OpenAI，Codex CLI/GUI，GPT5.4
Amazon，Kiro，Sonnet，
cursor，中转，20刀，透支40刀
Microsoft，GitHub Copilot，Sonnet4.5，GPT5.2，Gemini3
阿里，通义零码/Coder，Qwen
百度，Comate，文心
Kimi，Kimi Code，kimi
DeepSeek，deepseek-cli，v3
字节，Trae，Doubao
腾讯，CodeBuddy，Hunyuan
专注大模型的公司：GLM，MiniMax

知道了不同厂商的IDE，以及模型的特点。就可以充分发挥他们不同的特长。正如同管理团队，擅长沟通的同学，就去做跨团队协同；擅长钻研技术的同学，就去做搞底层技术。这样效率也高，同学们也感觉自己的工作有意思。

如何选择模型

通过显卡，部署开源模型。

有一些开源的模型

GLM 4.7
Qwen Coder
DeepSeek V3/R1
Kimi 2.5

长期来看推理成本较低，但是初期显卡成本较高。

购买服务

包月会员：pro，max。
购买API：按量付费。
商业站，号池。
公益站，CPA。Codex自动注册、绑卡。

四器：数字化转型：工作中的应用

4.1 黑客马拉松作品展示

1）AI巡检demo，重构工作流。

2）AI回归核心case，同步公司IM工具相关负责人。重构团队效能半径。

AI打开Cooper文档，查看回归case；
通过iPhone Mirrow打开APP
根据文档回归case中的步骤，查看第1个、第2个、第3个tab的现金贷、信用卡业务。
发现异常的问题404。
记录到Cooper中。
在Cooper中找到这个case的负责人。
打开IM工具，找到相应的群。
在群里@相应的负责人。

4.2 画图：流程图，时序图

通过自然语言描述，让AI生成staruml，渲染成图。

4.3 openSpec使用

openSpec init
openSpec propose
openSpec apply
openSpec archive
目录结构

openspec/
├── specs/
│ └── cashloan/
│ └── spec.md # 当前现金贷规范
└── changes/
└── creditCard/ # AI创建整个结构
├── proposal.md # 为什么和什么变更
├── tasks.md # 实施清单
├── design.md # 技术决策（可选）
└── specs/
└── cc/
└── spec.md # 显示添加内容的增量

4.4 生成一个可视化的 HTML presentation 来讲解陌生代码

你现在是一位经验丰富且擅长技术分享的高级开发者（Developer Advocate）。我有一段完全陌生的代码，需要你帮我快速理解。

请为我生成一个单文件 HTML（Single-file HTML）幻灯片，来循序渐进地讲解这段代码。

技术与排版要求：

使用 Reveal.js： 通过 CDN 引入 Reveal.js 的 CSS 和 JS，以及所需的主题（推荐使用 dracula 或 black 这种适合看代码的深色主题）。
代码高亮： 通过 CDN 引入 Highlight.js 进行语法高亮。
单文件输出： 所有的 HTML、CSS 和少量必要的内联 JS 都必须写在一个代码块中，方便我直接复制并保存为 .html 文件运行。

幻灯片内容结构要求：

Slide 1（封面）： 代码的简要说明（TL;DR），一句话总结它实现了什么功能。
Slide 2（架构/设计模式）： 宏观讲解这段代码的核心逻辑流或涉及的设计模式。
Slide 3 ~ 5（核心拆解）： 挑出代码中最核心的 3 个函数或代码块，每页 Slide 只讲一个。左侧放代码片段，右侧（或下方）放人话解释。
Slide 6（陷阱/关键点）： 这段代码中哪个部分最难懂？或者有什么巧妙的细节？

请将完整的 HTML 源码包裹在 ```html 代码块中。

以下是需要你讲解的代码：

4.5 用 ASCII 画协议/代码库结构图

请用 ASCII 字符画一个 [例如：获取乘客与外卖订单] 的核心时序图/架构图。

绘图指令：

请使用扩展的 Box-drawing 字符 (┌ ─ ┐ │ └ ┘ ├ ┤ ┬ ┴ ┼) 来绘制实体框，这样比纯加号和减号更好看。
实体框内部的文字需要居中对齐。
使用带有箭头的线条 (--->, <===, ...>, 等) 表示数据流向或请求顺序，并在箭头上/方标注动作和序号（如 1. Request）。
强制宽度限制： 整张图的宽度请控制在 80 个字符以内，防止在移动端或窄屏幕下换行导致排版崩溃。
将生成的 ASCII 图放在单独的代码块中。

4.6 阿尔法思维

渗透AI工作流。整合到自己的工作流，提升效率。做别人还没有想到的东西。

你现在的工作流，5年前会用吗？如果会用，说明最近几年没有更新技术了。快更新你的工作流吧，即使只有一点点改进。