AI Learning Blueprint(H1)：从 AI Coding 到 AI Workflow，我在 AI 小组这半年做了什么

前言 👋

如果要用一句话总结我上半年在 AI 小组做的事情，那不是“我学会了怎么让 AI 帮我写代码”，而是：我开始从 AI Coding 往 AI Workflow 走了。

这半年做的事情表面上很散：写 skills、搭工作流、做 JIRA 修复闭环、沉淀项目记忆、研究 Agent 协作、写分享文档、搞安装和推广。但如果往回看，会发现这些事情其实都在围绕同一件事打转：怎么让 AI 不只是补一段代码，而是真正参与研发过程，并且这套能力不只我自己能用，团队也能直接接起来用。

说白了，我现在越来越不信“AI Coding 提效”这种太轻飘飘的说法了。提效当然有，但如果只是快写两段代码，价值其实没那么大。真正值钱的，是它能不能把分析、定位、方案、改码、审查、验证这一整条链路跑通。单点提效谁都能吹，工作流跑不跑得通，才决定这玩意到底是不是生产力。

而且这半年我还有一个很直接的感受：做一个 demo 不难，做一个自己用着爽的东西也不难，难的是把它做成别人愿意装、愿意用、用一次没骂人、用第二次还想继续用的东西。 这也是为什么我后面越来越关注产品形态、稳定性、可复制性，而不是继续沉迷在“我又搞出一个新 skill”这种短期爽感里。

这篇文章就想复盘一下，我上半年在 AI 小组到底做了什么，想清楚了什么，沉淀了什么，又踩了哪些坑。

先看结论 📌

如果只用一张表来概括这半年，我大概会这样总结：

主题	这半年主要在做什么	我现在更在意什么
AI Coding	写 skill、接代码能力、提升单点效率	不只写得快，而是写得稳
AI Workflow	把需求、排障、修复、验证串成链路	流程能不能真正跑通
技能沉淀	把个人经验抽成可复用 skills	别人能不能装上就用
项目理解	补 RAG、memory、项目记忆	AI 能不能少“失忆”一点
产品化	写文档、做入口、统一交互方式	团队愿不愿意长期用

---

一、上半年到底在干什么？ 🧩

半年主线速览 🗺️

主线	代表内容	想解决的问题
高频工作流	daily-one-click、jira-one-click	把高频研发动作标准化
能力资产化	Dev-Skill 仓库、40+ skills	把“我会”变成“大家都能用”
产品化表达	分享文档、统一入口、安装方式	降低理解和接入门槛
项目理解增强	项目记忆、RAG、多层 memory	让 AI 真正理解上下文

1. 先把最高频的两类事情做成标准工作流 ⚙️

上半年我投入最多精力的，其实是两类非常高频的研发场景：

• 日常需求开发
• JIRA 修复 / 问题排查

围绕这两类场景，后面逐渐沉淀出了两条主链路：

• daily-one-click
• jira-one-click

这两条链路最重要的一点，不是“把 AI 接进来了”，而是开始让 AI 参与完整链路，而不是只在最后一步写代码。

以前大家聊 AI coding，很容易把注意力放在“这段代码生成得快不快、准不准”。但真干活的时候会发现，最耗时间的根本不是敲代码，而是前面的那一大坨：

• 需求到底在说什么
• 问题到底出在哪
• 日志怎么查
• 边界怎么定
• 方案怎么收敛
• 改完之后影响面怎么判断
• 最后怎么验证和收口

所以我后面的方向就越来越明确：不再盯着让 AI 帮我省一段代码的时间，而是想办法让它把整条研发流程跑得更顺。

这件事说起来像常识，但真做起来完全不是那么回事。因为你会发现，代码只是最后露在外面的那一层，前面那些分析、判断、切换上下文、对齐边界的动作，才是真正把人耗死的地方。AI 如果只能碰最后那 10%，那它再强也就那样。

2. 把个人经验从“我会”变成“别人也能直接用” 🔁

如果一套东西只有我自己会用，那它最多算个人技巧，不算真正的沉淀。

所以这半年我一直在做的另一件事，就是把自己的经验往 skills 和 workflow 上抽。把原来靠感觉、靠经验、靠多轮对话才能跑通的事情，尽量变成可以复用、可以安装、可以推广的能力资产。

到现在为止，已经陆续沉淀了 40+ 工程化 skills，覆盖的内容大概包括：

• JIRA 分析与修复
• 日志排查
• 技术方案编写
• 需求结构化
• 应用扫描
• Spec 驱动开发
• Code Review
• Agent 协作流程
• 项目记忆与上下文管理

这背后我自己的判断也变了。以前会更在意“这个能力我有没有”，现在更在意的是：

这个东西别人能不能拿起来就用。

如果不能，那它还是太依赖人，不够像产品。

而且我中间其实也踩过一个挺典型的坑：很容易沉迷在“再做一个 skill”这件事本身。 因为做 skill 有即时反馈，能跑起来就会很爽，看着数量涨也会有成就感。但后来回来一看，发现如果没有统一入口、没有场景边界、没有安装方式、没有配套说明，那很多 skill 本质上只是“作者自己最懂”的半成品。

所以我现在会更警惕那种“技能数量越来越多，看起来很繁荣，实际上别人根本接不住”的状态。

3. 从个人提效，慢慢走到产品思维 🧠

这是我上半年挺明显的一个变化。

一开始做这些东西的时候，还是会比较自然地从“怎么提高我自己的开发效率”出发。但越往后做，越会发现如果真想往组内推广、甚至做成更通用的 AI 产品，判断标准就得变。

不能只看“我自己用着爽不爽”，而要看：

• 够不够简单
• 稳不稳定
• 能不能复制
• 团队能不能低成本接起来
• 这个产品形态别人愿不愿意接受

比如我后面写《告别传统：用 Vibe Working 标准化日常开发和 JIRA 修复流程》，本质上就不是在介绍某个 skill，而是在试着把一套 AI 研发方式包装成团队可以理解、可以安装、可以快速见效的产品。

这件事对我影响挺大的。因为它让我慢慢意识到，做一个“能演示”的 AI 东西不算难，难的是把它做成别人真的愿意长期用的东西。

很多东西你自己用的时候会自动脑补，但别人不会。你知道下一步该点哪、该看哪、该怎么失败重试，不代表别人也知道。所以产品思维这件事，说难听点，就是别老拿自己的熟练度骗自己。

4. 开始补 Agent 最难的那一块：项目理解能力 🧭

如果说前面的工作是在解决“让 AI 会做事”，那我后面越来越在意的是另一件更底层的事情：

AI 到底怎么才能理解项目？

很多时候 AI 效果不好，不是因为它不会写代码，而是因为它根本不理解当前上下文：

• 不知道这个项目有哪些模块
• 不知道业务边界在哪里
• 不知道哪些文档是关键上下文
• 不知道哪些经验是已经达成的共识
• 不知道应该先调哪个 skill、看哪个文件、走哪条路径

所以我后面开始主动补这方面的东西：

• RAG
• 多层 memory
• 项目记忆
• 渐进式披露
• Agent 工程评估
• 多 Agent 协作方式

我现在会觉得，这些东西才是真正决定 AI 能不能从“会聊天、会补代码”往“能参与项目协作”升级的关键。

说得再直接一点，很多 AI 产品现在最烦人的地方，不是它笨，而是它老失忆。你今天刚教会它，明天又像新来的；你刚总结完一轮共识，下一轮它又从零开始问。这个问题不解决，模型再强都容易停留在“偶尔惊艳、长期难用”的阶段。

---

二、几个让我印象很深的真实案例 💡

1. daily-one-click：不是帮我写，而是帮我把开发链路搭起来 🛠️

daily-one-click 这条线，最开始我想解决的并不是“让 AI 直接产出代码”，而是日常开发里前面那一长串容易散、容易断、容易来回反复的工作。

以前一个需求过来，人脑里其实会自动做很多切换：先理解需求，再澄清范围，再整理 PRD 或方案，再分析影响应用，再决定用什么开发方式，最后才是写代码。问题在于，这一套东西如果不沉淀，永远只能靠人顶着干。

daily-one-click 想做的事情，就是把这条链路尽量标准化，让需求从“我知道要干什么”，变成“AI 和人都知道下一步该怎么推进”。

这件事带来的最大变化，不是省了几分钟，而是让我开始把“开发”看成一个可以被编排的流程，而不是只靠熟练工经验硬顶。

而且这条线还有个很现实的价值：它能把很多原本藏在脑子里的默认动作摊开。以前你觉得“这不就是正常开发流程吗”，但真要让 AI 跑、让别人复用的时候，才会发现所谓“正常流程”里其实藏了大量默认知识，不拆出来就永远传不下去。

2. jira-one-click / jira-trace-fix-cr：AI 真正能打的地方是排障闭环 🚨

如果说哪条线最能体现 AI Workflow 的价值，我觉得还是 JIRA 修复这条。

因为排障这件事本来就不是纯代码问题，它天然就是一条长链路：

• 先看 JIRA 在说什么
• 抓关键词、时间窗、环境、应用线索
• 找 traceId
• 查日志
• 顺着调用链看根因
• 判断是配置问题、代码问题还是数据问题
• 如果要改代码，再继续走修复、CR、验证

这里面随便断一环，后面都跑不起来。

所以我后面比较坚定的一点就是：AI 最值得用的地方，不是让它凭空生成一坨代码，而是让它参与这种本来就很依赖上下文和步骤感的排障闭环。

尤其是像 jira-trace-fix-cr 这种思路，核心不是“帮我分析一下”，而是尽量别停在分析层，而是一路往下走到修复和收口。这一点我现在挺看重的，因为只分析不落地，很多时候意义没那么大。

说白了，JIRA 这种场景太适合拿来检验 AI 到底是不是生产力了。因为这里没法靠花哨输出混过去，链路断了就是断了，根因没找对就是没找对，修不了就是修不了。它很残酷，但也很诚实。

3. Dev-Skill 仓库：沉淀 skill 不是目的，能安装、能复用才是目的 📦

上半年还有一条比较重要的线，就是 Dev-Skill 仓库。

一开始沉淀 skills 的时候，很容易陷入一种爽感：做出来一个能用，做出来两个也能用，数量涨得很快，成就感也很强。但后面我慢慢发现，skill 多不等于体系强。

如果这些 skill：

• 只有我知道怎么触发
• 只有我知道适合什么场景
• 只有我知道和别的 skill 怎么配合
• 别人装上以后还是不会用

那它本质上还是“个人能力外挂”，不是团队资产。

所以我后面越来越在意 Dev-Skill 仓库的另一面：

• 能不能安装
• 能不能统一维护
• 能不能被龙虾这类 Agent 直接消费
• 能不能形成迭代机制
• 能不能被团队拿去复用

这也是为什么我会越来越把“skill 仓库”看成一个产品，而不只是一个文件夹。

而且这里还有个反直觉的地方：东西越多，不一定越强，很多时候反而越乱。 后面我明显感觉到，workspace 里的 skill、本地 skill 一多，Codex 会出现误触发和不触发的情况，这其实已经和 skill 最开始想强调的“渐进式披露”打架了。所以我现在很明确，后面不能再无脑堆技能了，必须补路由。

4. 项目记忆：我越来越觉得这是决定 AI 上限的关键 🧠

还有一条我自己越来越笃定的线，就是项目记忆。

很多时候你会觉得 AI 这次回答不错、下次又不行，不稳定得很烦。再往下拆，最后会发现很多问题不是模型本身抽风，而是它每次都像重新入职。

它不知道：

• 你这个项目之前怎么做过
• 哪些结论已经讨论过
• 哪些约定其实是默认共识
• 哪些文件该优先看
• 哪些技能该先用，哪些不该碰

所以“让 AI 拥有项目记忆”这件事，在我看来不是锦上添花，而是决定它能不能真正进入生产环境的关键。轻量、渐进式披露、持续记忆，这几个词我现在越来越看重，也是因为它们更接近真实可用，而不是堆一个大而全的上下文把模型喂爆。

这个方向我现在甚至会觉得，比“再换一个更强模型”还重要。因为模型强了，只是上限高一点；但如果记忆、上下文、项目理解还是一塌糊涂，那它的可用性依然会反复横跳。

---

三、这半年我最大的几个认知变化 🔄

1. AI 的价值不在单点生成，而在流程打通 🔗

这是我现在最明确的一个判断。

单点编码提效当然有，但它的上限其实没那么高。真正有复利的，是把分析、定位、方案、改码、审查、验证这些环节串成一条链。

一旦链路能跑通，AI 带来的就不只是“快一点”，而是研发方式本身开始变化。

2. 做 AI 产品，核心不是功能多，而是“能被用起来” 🎯

这点在做推广和沉淀的时候体会特别深。

做一个 skill 不难，做十个也不算最难。真正难的是：

• 别人知不知道该用哪个
• 别人第一次用会不会卡住
• 安装门槛高不高
• 成本是不是够低
• 结果稳不稳
• 团队愿不愿意持续用

所以后面我越来越觉得，AI 产物要想推广，本质上得像产品，而不是像一堆功能说明书。

3. Skill 不能无脑膨胀，必须有路由 🚦

这是我最近感受很强的一点。

随着 workspace skill、个人本地 skill 越来越多，开始出现一个明显问题：skill 误触发和漏触发。

这和 skill 一开始主打的“渐进式披露”其实是相违背的。因为技能一多、命名一杂、边界一重叠，模型就容易：

• 调错 skill
• 该调的不调
• 多个类似 skill 之间犹豫
• 触发路径不稳定

所以我现在的判断是：不能靠无限堆技能解决问题，必须有一个类似路由器的东西，去解决技能选择和触发的问题。

不然 skill 体系越大，使用体验可能反而越差。

4. 做 Agent，自己也得不断补课 📚

“活到老学到老”这句话，我现在还挺有感触的。

龙虾出来以后，我越来越觉得自己不能只停留在代码和业务上。因为如果要真正做好 Agent 开发，很多知识都得补：

• RAG 怎么搭更合理
• memory 怎么分层
• Agent 工程怎么评估
• 多 Agent 协作怎么设计
• 什么样的上下文组织方式更稳定
• 什么样的技能设计更符合模型工作方式

这半年我不只是“做项目”，其实也在重新学习一套新的工程方法。

认知变化速览表 ✨

过去更关注	现在更关注	背后的变化
AI 会不会写代码	AI 能不能跑通流程	从点状提效走向链路提效
我自己会不会用	团队能不能低成本接入	从个人技巧走向产品能力
skill 数量多不多	skill 路由稳不稳	从堆能力走向做调度
模型够不够强	项目理解够不够深	从模型中心走向上下文中心

---

四、哪些东西值得继续沉淀？ 🌱

如果从“长期有复利”的角度看，我觉得下面这些最值得继续投。

1. 高频工作流 🔁

像日常需求开发、JIRA 修复这种高频且流程相对稳定的场景，最值得持续打磨。因为它们最容易形成团队级复用。

2. 技能仓库 🧰

技能仓库的价值不只是多，而是是否形成：

• 清晰分类
• 稳定调用
• 易于安装
• 可持续迭代
• 有使用反馈闭环

如果这几点能持续做好，它会是非常重要的 AI 能力资产。

3. 项目记忆 / 上下文体系 🗂️

这是我觉得最关键、也最容易被低估的一块。很多 AI 效果问题，最后都不是模型问题，而是上下文问题。

4. 路由与调度能力 🚦

skill 体系一旦做大，没有路由层肯定会出问题。这块后面非常值得专项沉淀。

5. 可分享的方法论文档 📝

以前总觉得“会做就行”，但现在越来越觉得，能讲清楚、能写出来、能让 AI 和人都能读懂，本身就是生产力。

---

五、哪些地方做得还不够好？ 🪫

当然也不是所有事情都很顺。

1. 技能膨胀带来的复杂度上升 📈

skills 越多，管理越难，触发越不稳定，用户也更难理解整体结构。

2. 产品形态还不够统一 🧱

有些东西已经像产品了，有些还停留在“高手工具”阶段。要推广，必须进一步收敛交互和入口。

3. 项目理解能力还不够强 🔍

虽然已经开始做项目记忆、RAG 和多层 memory，但离“真正理解项目”还有距离。

4. 经验沉淀速度还不够快 ⏳

很多有价值的经验，还是停留在具体对话和个别案例里，没有第一时间抽成可复用资产。

当前问题清单一览 ⚠️

问题	现象	后续方向
技能复杂度上升	skill 越多越难管理，触发不稳定	做好分类、边界和路由
产品体验不统一	有些能力像产品，有些还是高手工具	收敛入口和交互方式
项目理解仍偏弱	AI 还不够懂项目上下文	继续补记忆、RAG、项目知识
沉淀效率不足	经验容易散落在对话和案例里	更快抽成文档和可复用资产

---

六、我现在怎么理解这半年？ 🪞

如果回头看，我觉得这半年最重要的，不是做了多少个 skill，也不是写了多少篇文档，而是我对 AI 在研发里的位置有了更清晰的判断：

AI 不该只是一个“帮我写代码”的助手，而应该逐步成为一个能理解上下文、调用能力、参与协作、跑通流程的工作伙伴。

而要走到这一步，靠的不只是模型本身，还包括：

• 工作流设计
• skill 设计
• 路由与调度
• 记忆与上下文
• 产品化包装
• 团队推广方式

这些东西拼在一起，才有可能真正做出一个“能被持续使用的 AI 研发产品”。

---

七、下半年想继续往哪里走？ 🚀

下半年方向速览表 🗓️

方向	目标	关键词
工作流继续产品化	让更多人更低成本接入	入口统一、体验收敛
补强 skill 路由	降低误触发和漏触发	路由、调度、边界
继续做项目记忆	让 AI 拥有长期上下文	memory、项目理解
完善 Agent 工程方法	从 demo 走向稳定范式	方法论、工程化
持续输出分享内容	沉淀团队和 AI 都能复用的知识	文档、复盘、传播

接下来我更想继续做几件事：

1. 把工作流继续产品化
   让更多人能更低成本接入和使用。

2. 补强 skill 路由能力
   解决 skill 膨胀后的误触发、漏触发问题。

3. 继续做项目记忆
   让 AI 真正拥有长期上下文，而不是每次都从零开始。

4. 完善 Agent 工程方法
   不只做 demo，而是形成更稳定的开发范式。

5. 持续输出可分享内容
   把做过的事、踩过的坑、有效的方法讲清楚，变成团队和 AI 都能复用的知识资产。

---

结语 🌌

上半年这段探索让我越来越确定一件事：AI 的未来，不只是更强的模型，而是更像样的工作方式。

如果说以前我关注的是“AI 能不能帮我快一点”，那现在我更关心的是：

能不能把一套靠谱的 AI 工作方式沉淀下来，让它不依赖某一个人的经验，也能持续发生价值。

这件事可能比“写出一段漂亮代码”慢得多，也难得多，但我觉得更值得做。