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小时响应，大家需要轮流晚上值班。难免会有半夜被电话吵醒的经历。面对半夜被吵醒而失眠这个问题，应该怎么办？

两年之前，这种问题只能去看医生，或自己读书寻找答案。如果去看医生，医生听到你仅仅是因为值班，偶尔失眠。可能都懒得回答你的问题，三分钟就把你打发走了。如果自己探究答案，需要自己看几本书，系统性的了解睡眠认知疗法。需要尝试一些通用的方法，探索具体哪些方法更适合自己。仅仅是阅读几本书，熟悉整个体系，这也是不小的成本。

在知识平权时代，AI就是有博士级别的私人助手，他能根据你的情况，针对性的做出建议。其实不仅是生活中的知识，在工作中，对于工作中占据很重要席位的Coding，AI已经非常擅长了。那么AI 在团队中应该占据什么样的位置呢？

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

如果把公司的组织架构简化成四层：头部管理者，腰部管理者，腿部管理者，一线员工。那么，AI属于哪一层？

按照2025年5月红杉资本闭门会的预测，未来会出现一人独角兽公司。有了大量Agent，都由一个人负责，然后交付结果。显而易见，每个人都可以用AI，按照正常的思路来，其实就是在最下面一层。一个人可以带一个团队。
用了两年AI Coding之后，我发现其实并非这么简单。

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

其实一个小项目，交给应届生，甚至是一些比较厉害的实习生来做，他其实是能够完全做完的，中间可能会有沟通，但是他会全部做完，并且负责任的。如果他不会，也会明确表明自己搞不定。
AI与人不一样的地方，就在于AI不负责任。并且他不会说不能做，任何问题他都能做，无非是做错，而且还不告诉你。如果你不懂，那么就很容易被坑。责任和决策是相互绑定的，不负责任，就不能做决策。

从2024年至今用AI，写了接近200万行代码。尝试做了大量的项目，有过大量高效的经历，也有失败的经历，因为没有及时git提交，导致大量写好的代码又丢失，而且无法恢复。

目前对AI的理解就是：人要在其中做大量微决策。要完全主导，而不是完全交给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无法保证100%正确。（下一章介绍这个问题，AI只是概率的预测）。

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

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

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

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

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

在古代无论是西方马基雅维利的《君主论》，还是东方法家的《韩非子》，在当时历史环境下都能极大提高生产效率。
但是随着科技的发展，人们知识水平的提高，信息的流通性增加，彼得德鲁克的管理思想开始流行。但是很多人还是多劳多得的思想。
随后谷歌的赋能出现，很多互联网公司，以及传统企业胖东来，都给一部分极端有潜力的员工更多的期权激励。他们不再把在公司工作当成一种赚钱的方式，而是认为这工作就是我的一部分，公司和我就是一体的。这样可以创造出巨大的价值。局部来说这样效果很好，但是整体来说，这样的人太少了。
在AI时代，是否可以再次使用《君主论》与《韩非子》的思想，让AI来达到10倍，甚至更高的效率呢？毕竟AI全天24小时干活也不会累。

从个人角度来看，设计时间不对称的工作流，确实可以拥有 AI 时代的杠杆。虽然个人是企业的一部分，但是对企业来说，个人效率即使提升10倍，依然不能带来组织层面的整体效率飞跃。
一方面是因为整条业务链路，并不能完全自动化。还是需要涉及人的确认。
另一方面，是因为个人在整条链路中，不能做全部决策。
这其实是基于18世纪亚当斯密的《国富论》的底层原理：想要提高组织效率，就需要分工细化。每个人做其中的一个螺丝钉，这样能保持组织效率极其高。现在大厂都是这样做的。
但是这也会有另外一个问题，在AI时代可能会成为了瓶颈，即自己只能决策自己的一部分。比如整条业务链路，从产品、交互、研发、风控、策略、测试。一名研发，不能为产品做决策，遇到交互问题，还是需要请产品、交互同学来做决策。那这就阻断了整条自动化流程。本来AI十分钟就能搞定的交互、视觉、产品功能。如果找人，算上预约会议，没有个1天很难搞定。
于是就有企业尝试横向发展，即全栈工程师，一名研发做前端、后端，甚至加上测试。再后期可能连产品、交互也可以由研发一个人搞定。当然这一个人，之前具体是什么岗位，即谁取代谁，那就不好说了。
这是横向发展的思路。但是这也有一个问题，就是每个人的认知是有上限的。比如本文配套对应的PPT，是用AI做的，可以看到其界面比较酷炫，给我一个星期，甚至一个月的时间，我能做出来么？显然做不出来，因为我完全不懂设计审美。这不是时间的问题，而是根本不擅长做这一方面。

另外还有纵向发展的思路，即一个人深入钻研某一个方向，将这一个方向的效率提高10倍。比如一个方向小组有10个人，同时做5个项目。即每个项目需要2个人。那么朝着单个方向效率的提升，是否可以一个人代替6个人，同时做3个项目呢？

当然无论是横向，还是纵向发展，其实都是需要一种在AI出现之前都需要的能力：链接。平时做需求的时候，如果对于某一个复杂功能，研发层面涉及到很多个团队：FE、客户端、API、风控、策略。就很容易出现技术方案涉及的遗漏、功能影响面评估不全面等问题。那其实是因为很少有人能够了解整条业务链路。每个人都是深耕自己的一个方面。所以其实不仅是AI时代，在任何时代。都要求对不同方面的知识体系，能够进行链接。了解整体链路。

1.6 效率太高的弊端

科技的发展具有两面性。
在移动互联网，算法推荐时代就比较明显。虽然给人带来了更精准的信息推荐，但同时也带来了危害：一些不具备自制力的学生，甚至成年人，沉迷在信息茧房之中无法自拔。
AI的发展，确实提升了效率，但是也迎合了人性脆弱的一面：喜欢简单的事物。既然写代码这么简单，那完全让AI干不就行了么，有问题让AI修复、再测试不就行了么。如果自己有丰富的架构设计经验，那么可以约束、限制、Review代码，但是如果自己本来就不熟悉，再不进一步训练写代码的技能，完全依赖AI，那么就会导致自己还是学不到核心技术。当AI能够完全胜任简单的模块开发，打破流程的间断性，能够自动化完成的时候，靠时间、加班堆积出来的品质将毫无意义。而稀缺、更核心的能力却依然有用武之地。

最近校招就会发现部分应届生使用AI回答问题。特别是当低年级同学听到学长介绍这种方法，那就更加加重了懒惰的心里。有些学生眼神位置保持的比较好，确实看不出来。但是通过这种方式获得的工作，入职后不就就会发现难以适应。

因此利用AI训练自己的能力，找到一位免费的、给自己反馈的老师，就是AI赋予的礼物。其实不仅Coding，其他方面也可以参考类似的思路。
比如英语的学习，虽然看文章可以用AI翻译，但是利用AI学习英语也是很好的机会。以前找私教练习口语，一个小时起码得100元。而现在100元能买一个月的会员，和AI随便对话练习。

这些技能的学习，其效果并不仅仅在于技能之上，而在于大脑的训练。学习这些是训练大脑的一次机会。有一些高端技能的训练，AI是无法辅助的。比如冥想，如何觉察到自己的快思考，觉察到自己的无意识行动。纠正、优化自己之前有问题的行为习惯。否则以后当有大量时间，而又不知道要干什么的话，很容易出现心理问题。这些问题不仅影响的是自己，还会给家里的成员，特别是孩子造成更深远的影响。

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

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

2.1 预测模型

AI（尤其是大语言模型）本质上是基于概率的预测模型。它更擅长生成“概率上合理”的内容，而不是“绝对正确”的内容。所以，基于目前的技术架构来看，AI很难达到100%正确的程度。

幻觉：难以完全避免的失效模式

AI 最危险的不是“答不上来”，而是“答得太像真的”。AI 常见的两种失效模式：
1 幻觉型（Hallucination），表现：非常自信

编论文
编 API
编法律条款
编不存在的概念

2 上下文漂移（Context Drift）

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

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

诺贝尔经济学奖得主丹尼尔·卡尼曼《思考，快与慢》，提出了人有快、慢思考，快思考是无需可以思考的快速反应，比如开车的时候看到前车刹车灯亮了，这个时候不用思考，直接就会踩刹车。

因为LLM是按照概率预测，其行为更接近快思考这种行为模式。但是通过强化学习与推理策略优化，AI开始表现出类似“慢思考”的行为特征。

LLM（大语言模型）的训练分为预训练，后训练。
后训练包括：

SFT（微调，指令学习）
偏好对齐（RLHF / RLAIF / DPO），强化学习
安全对齐（Safety）
工具增强（Tool / Agent / Function）

随着模型规模与训练方式的演进，开始出现涌现现象，出现类似人类慢思考的能力。

2.3 Scaling Law缩放定律

半导体行业的发展长期遵循摩尔定律，即每18个月性能翻一倍。其瓶颈主要来自芯片制程与物理极限。不过CPU是串行操作，线性依赖，后一步的计算必须等待前一步的结果。而显卡的迭代速度，比CPU还要快。

2020年《Scaling Laws for Neural Language Models》这篇论文，提出了AI有清晰可预测进步。所以2022年就有4名学生辍学创办了Cursor，虽然在2022，甚至2023年，AI Coding仍然不被主流认可，但是按照当时的可发展速度的预测，他们坚信这个方向是对的。没过几年，25岁年收入就达到数亿美金。

2024年6月Stable Diffusion 3开源，当时就爆发了电商内容生成的需求，不过当时还是有一些电商门槛的。
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来使用rg, awk, sed, grep等命令。

AI了解代码的方法

Bash：rg, awk , sed, grep, find, ls, cd, head, search(pattern:)
MCP，通用工具接口协议：操作文件系统、IDE、浏览器、数据库、桌面GUI、Bash/PowerShell

LSP

Bash命令进行全局扫描，会被当成长文本理解，噪声较多。去年LSP被引入到AI Coding领域，通过解析代码形成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等Spec-Driven Development（SDD），通过规范化的文档约束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	炫目表演中	暗示正在准备给你展示一个“惊艳”结果
Ruminating	沉思中	暗示AI正在反复思考、深思熟虑
Scurrying	急促奔跑中	暗示AI像小动物一样手忙脚乱地为你跑腿、找文件
Simmering	慢炖中	暗示想法正在“锅”里慢慢酝酿
Tomfoolering	搞怪中	最明显的幽默，暗示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）

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可以切换模式。对于简单的需求，可以直接使用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/i18nCLProduct
~/.cc/rule/i18nCCProduct
~/.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/CLProduct
   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完成过多的任务。

1 简单需求，应该在两轮对话内完成。如果做错了，重新来（clear git reset），不要纠正。但是自己可以把避免这个错误放到原始 prompt后面。否则纠正的话，AI就会说：”您说的对”。
2 复杂需求，使用planmode，在设计阶段指出错误，反复商量、修改plan。最后一次性完成。注意，要保证在完成时还有10%左右的 context可用。如果context不够了，拆分需求，直到可以在一个context内完成。
3 context 用到60%就差不多了，不要使用/compact。如果不够用，就拆分任务。

3.12 不同 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	GPT-5.4
Amazon	Kiro	Sonnet
Cursor	中转	20美元（可透支40美元）
Microsoft	GitHub Copilot	Sonnet 4.5、GPT-5.2、Gemini 3
阿里	通义零码 / 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 黑客马拉松作品展示

AI巡检demo，重构工作流。

AI回归核心case，通过公司的通讯软件同步相关负责人。重构团队效能半径。

4.2 画图：流程图，时序图

通过自然语言描述，让AI生成PlantUML，渲染成图。如果涉及团队多，流程复杂。如果人工手画，这可不轻松。

4.3 openSpec使用

openSpec init
openSpec propose
openSpec apply
openSpec archive

目录结构

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

4.4 用可视化的 HTML presentation 讲解代码

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

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

**技术与排版要求：**

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

**幻灯片内容结构要求：**

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

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

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

比如关于深度链接的代码的讲解，效果如图。因为不同的模型，效果差异较大。普通模型可以看到如图的效果。

4.5 用 ASCII 画代码库结构图

请用 ASCII 字符画一个 [相关需求] 的核心时序图/架构图。

**绘图指令：**

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

如下是生成的ASCII图，在终端看着还不错，这里看个别位置有些偏移。


┌─────────────────────────────────────────────────────────────────────────────┐
│                        Tab ViewController 工厂模式架构                        │
└─────────────────────────────────────────────────────────────────────────────┘

                              ┌───────────────────────┐
                              │   <<protocol>>        │
                              │ KQYTabViewController  │
                              │    FactoryProtocol    │
                              └───────────┬───────────┘
                                          │
                    ┌─────────────────────┼─────────────────────┐
                    │                     │                     │
                    ▼                     ▼                     ▼
      ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
      │CCProductVCFactory  │ │CLProductVCFactory    │ │  MineVCFactory      │
      │  ─────────────────  │ │  ─────────────────  │ │  ─────────────────  │
      │ +canCreateForTag:   │ │ +canCreateForTag:   │ │ +canCreateForTag:   │
      │ +createVCForTag:    │ │ +createVCForTag:    │ │ +createVCForTag:    │
      └─────────────────────┘ └─────────────────────┘ └─────────────────────┘
              │                       │                       │
              │ tag="CCProduct"      │ tag="CLProduct"        │ tag="mine"
              ▼                       ▼                       ▼
      ┌─────────────┐         ┌─────────────┐         ┌─────────────┐
      │CCProductVC │         │ CLProductVC  │         │  MineVC     │
      └─────────────┘         └─────────────┘         └─────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                         FactoryManager (单例)                                │
├─────────────────────────────────────────────────────────────────────────────┤
│  factories: NSMutableArray<FactoryProtocol>     // 注册的工厂列表            │
│  viewControllerCache: NSMutableDictionary       // VC缓存                    │
├─────────────────────────────────────────────────────────────────────────────┤
│  +sharedManager                                  // 单例入口                 │
│  +registerFactory:                               // 注册工厂                 │
│  +createVCForTag:hasLogin:model:                 // 创建/获取VC              │
│  +clearCachedViewControllers                     // 清空缓存                  │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                              创建 VC 时序图                                   │
└─────────────────────────────────────────────────────────────────────────────┘

  Caller                FactoryManager              Factory               Cache
    │                         │                        │                    │
    │  1. createVCForTag:     │                        │                    │
    │     hasLogin:model:     │                        │                    │
    │ ───────────────────────>│                        │                    │
    │                         │                        │                    │
    │                         │  2. 生成cacheKey       │                    │
    │                         │     "tag_login_uid"    │                    │
    │                         │                        │                    │
    │                         │  3. 查询缓存           │                    │
    │                         │ ──────────────────────────────────────────>│
    │                         │                        │                    │
    │                         │<────────────────────────────────────────── │
    │                         │     cachedVC (nil)     │                    │
    │                         │                        │                    │
    │                         │  4. 遍历factories      │                    │
    │                         │     canCreateForTag?   │                    │
    │                         │ ──────────────────────>│                    │
    │                         │                        │                    │
    │                         │<───────────────────────│                    │
    │                         │     YES                │                    │
    │                         │                        │                    │
    │                         │  5. createVCForTag:    │                    │
    │                         │     hasLogin:model:    │                    │
    │                         │ ──────────────────────>│                    │
    │                         │                        │                    │
    │                         │<───────────────────────│                    │
    │                         │     newVC              │                    │
    │                         │                        │                    │
    │                         │  6. 存入缓存           │                    │
    │                         │ ──────────────────────────────────────────>│
    │                         │                        │                    │
    │<─────────────────────── │                        │                    │
    │     return newVC        │                        │                    │
    │                         │                        │                    │


┌─────────────────────────────────────────────────────────────────────────────┐
│                              缓存 Key 策略                                    │
└─────────────────────────────────────────────────────────────────────────────┘

   cacheKey = "{tag}_{loginStatus}_{uid}"

   示例:
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ "CCProduct_login_12345"    → 已登录用户12345的CC产品线Tab VC               │
   │ "CLProduct_unlogin_12345"    → 未登录用户的CL产品线Tab VC                    │
   │ "mine_login_12345"          → 已登录用户12345的我的Tab VC                 │
   └─────────────────────────────────────────────────────────────────────────┘

   优势: 不同登录状态、不同用户的VC独立缓存，切换账号时不会复用错误数据


┌─────────────────────────────────────────────────────────────────────────────┐
│                              设计模式总结                                     │
└─────────────────────────────────────────────────────────────────────────────┘

   ┌────────────────┐         ┌────────────────┐         ┌────────────────┐
   │  抽象工厂模式   │         │   单例模式     │         │   缓存模式     │
   │  ────────────  │         │  ────────────  │         │  ────────────  │
   │  解耦Tab创建   │         │  全局唯一管理  │         │  复用VC实例    │
   │  易于扩展新Tab │         │  统一注册工厂  │         │  避免重复创建  │
   └────────────────┘         └────────────────┘         └────────────────┘

4.6 阿尔法思维

主动探索和尝试，在任何时代都很有必要。无非是在以前，这个提升效果不明显。虽然只有2%，甚至1%的提升，却需要不小的学习成本。但是AI带来的提升效果，可不是这么小的量级。特别是这个月月初开始，大家在公司都可以明显感受到这种变化。

不过AI的探索和尝试，在传统学习能力的要求之上，还要增加两个更高的要求：时间上的疯狂和物质投入。

时间上的疯狂。除了工作，吃饭，睡觉，其他时间尽量都聚焦在AI Coding。因为发展的速度太快了，而且这些技能需要实践。有点类似上学的时候学设计模式，仅仅看书是不够的，关键是要写代码，在项目中实践。如果仅仅是下载了几个Skills，就想让流程自动化，那么一定会有技术债，甚至线上问题。所以亲自用AI写代码的量一定要足够。

物质的投入。之前在工位买了2台显示器，鼠标，键盘，用于更大的视野，以及保证手肘与地面水平。吃饭聊天的时候也经常谈到这些设备的重要性。但是当听说一台显示器9500元的时候，劝退了不少同学。其实这些投入是长期有益的，特别是缓解视觉疲劳，虽然每个1小时眺望一下远方也是可行的。不过有些同学不感觉视觉疲劳，所以认为作用也不明显。
但是AI带来的提升就不一样了，其效果太明显了。最近各家都在探索自动化流程，谁能把这个流程做出来，那长期的收益太明显了。但是前期投入也是比较大的。比较激进的团队3个人，做出来自动化流程，半个月开销就高达7位数。

你现在的工作流，5年前在用吗？如果5年内都没有变化，说明已经多年没有更新技术了。快用AI更新自己的工作流吧，即使只有一点点改进。