AI 落地案例集

01 写在前面：让每一次 AI 实践，成为更多人的起点

AI 能做什么，我们已经听过很多答案。但回到每天的工作里，大家往往还有更具体的问题：手头这件事，能不能交给 AI？从哪里开始？遇到问题怎么解决？做完之后，到底有没有帮助？

我们整理这份「AI 落地案例集」，就是想从一个个真实的实践里，找到这些问题的答案。

这里收录的，是极客时间用户在工作和学习中使用 AI 的经历。有些尝试从一项重复的任务开始，有些源于一个困扰已久的问题，也有些只是抱着“试试看”的想法，一步步做出了能用的东西。

我们希望把这些过程留下来：面对什么问题，为什么想到用 AI，具体怎么做，中间遇到了哪些困难，最后带来了什么变化。让读者在看到成果的同时，也能找到可以参考的方法，为自己的第一次尝试多一点把握。

感谢每一位愿意分享的案例贡献者。

把自己做过的事重新梳理清楚，把踩过的坑、试过的方法和积累的心得写下来，需要时间，也需要耐心。正是你们的投入，让这份案例集有了具体的内容，也让更多人有机会从彼此的实践中获得启发。

这份案例集会持续征集、陆续更新。 眼前的内容是一个开始。我们期待随着更多人的加入，记录下更多场景里的探索，也看到同一个想法如何被不同的人借鉴、改进，长出新的可能。

如果其中某个案例让你想到“我的工作里好像也能这样试试”，欢迎从手边的一件小事开始。遇到问题，可以来交流；有了进展，也欢迎回来分享。

加入案例交流群

想进一步了解案例中的做法，交流自己遇到的问题，或关注案例集的后续更新，欢迎加入我们，一起边做边聊。

👇【加入案例交流群】👇

提交你的 AI 实践

如果你已经用 AI 解决了一个具体问题，欢迎把这段经历分享出来。不必等到成果足够“大”，也不必担心文笔如何。一个真实的问题、一段具体的过程、一份有用的经验，都值得被记录。

后续我们也会协助梳理和打磨内容，模板参考👉http://gk.link/a/12Mtj

👇 【提交你的 AI 实践】👇

02 从「人肉审查 + 手工补测」到「增量审查 + 单测自动化流水线」：提测缺陷逃逸率直降 58％，单次 PR 审查成本不到 5 分钱

案例名称

构建基于 AST 语义切片与沙箱自愈的「增量代码审查与单测自动化流水线」，实现 AI 驱动的代码审查与单元测试自动化。

案例简介

我们团队负责多条核心业务线，老旧模块与微服务交织，每周双周迭代、发版节奏极快。长期被三个工程问题卡住脖子：代码审查（CR）沦为形式或严重拖慢节奏、单元测试严重欠债、通用 AI 工具又无法直接落地。

最终我们自研了一套「轻重分离 + 沙箱自愈」的自动化流水线，无缝嵌入 GitLab CI/CD，让 AI 承担增量代码审查与单测生成的核心工作。

试点 3 个月后，单 PR 审查响应耗时从 40 分钟降至 3 分钟以内，有效单测行覆盖率从 30% 提升至 68% 以上，提测缺陷逃逸率下降 58%，且单次审查的 Token 成本被压在 0.05 元以内。

之前的老方案是什么，存在什么问题

接入 AI 之前，主要依靠传统静态扫描工具与纯人工防护：

1. 静态扫描（SonarQube / Checkstyle）：只能检查基础命名规范和固定规则的坏味道，完全无法理解跨方法调用关系和业务边界逻辑，误报率高，也抓不住运行时的深层缺陷。
2. 人工肉眼 Review：完全依赖资深架构师或 TL 人肉排查，效率极低，PR 平均积压流转时长达 4 小时以上；人在疲劳时极易漏审隐蔽的边界条件。
3. 人肉补单测：项目迭代压力下，开发普遍只写少数 Happy Path，边缘分支和异常捕获分支几乎没人愿意写；提测后全靠 QA 团队大范围人肉黑盒测试，测试周期长、反馈滞后。

三个具体痛点：

• 资深开发每天在 GitLab PR 上要花 1.5~2 小时评审，精力全耗在抓空指针、线程安全隐患、未释放资源、RPC 重试漏配等防御性低级问题上，业务逻辑和整体架构反而没空深看；
• 单测覆盖率长期卡在 30% 上下，边界 NullPointer 和状态机漏判经常逃逸到预发甚至生产环境；
• 一开始试过让团队在 IDE 插件或网页端用大模型补单测，结果 80% 的代码根本无法通过编译——模型频繁臆造不存在的私有方法、缺失项目特定上下文，反而给开发添乱，团队一度对 AI 落地产生抵触。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

我们没有简单地把整个代码库无脑喂给大模型，而是设计了一套「轻重分离 + 沙箱自愈」的自动化流水线，嵌入团队现有的 GitLab CI/CD 工作流，核心由三个环节组成：

1. 增量语义裁剪（Context Pruning）：通过 Git Diff 提取增量改动，利用 Tree-sitter / AST 分析提取受影响方法的调用上下游契约（Call Graph 与相关 DTO），只把高密度相关的上下文喂给模型，彻底避免全量上下文带来的 Token 浪费与模型幻觉。
2. 两阶段审查机制（Two-Stage Review）：第一阶段用本地规则与轻量模型快速过滤语法规范和静态坏味道；第二阶段设计严密约束的 Prompt 与 JSON Schema，专门针对并发竞态、事务传播、资源未关闭、未处理异步异常等 P0/P1 风险做语义审查，直接以 Inline Comment 形式挂在 PR 对应代码行，开发者一键即可确认或忽略。
3. 沙箱反馈驱动的单测自愈闭环（Test-Runner in the Loop）：模型按变更代码生成单测骨架后，流水线立刻启动轻量 Docker 沙箱执行测试；若编译报错或断言失败，将堆栈报错与失败代码自动回传模型，触发自愈重试（上限 2 次）；只有在沙箱中真正跑通、断言生效且覆盖目标分支的代码，才会提交到该 PR 分支。

过程中踩过的坑：

1. 上下文裁剪“裁过头”导致漏审或误报：AST 提取调用链时，遇到接口多实现、反射、Spring 依赖注入、动态代理、事件监听这类场景，静态分析找不到真实调用方，模型拿到不完整上下文就会凭空猜测，产生幻觉式评论。
   → 经验：对这类场景设置兜底策略，上下文置信度低时宁可多给一层上下游，或直接降级为“仅提示、不下结论”。
2. 评论噪音太大，开发者很快“免疫”：早期模型什么都想说，一个 PR 挂十几条评论，开发者开始一键忽略，真正的 P0 问题也被淹没。
   → 经验：严格限制评论数量上限，只输出 P0/P1；要求模型给出触发条件和证据代码行，拿不出证据的不发；把“忽略”的反馈数据收集起来，反哺 Prompt 和过滤规则。
3. JSON 输出不稳定：模型偶尔输出格式错误、行号偏移，导致 Inline Comment 挂错位置甚至接口调用失败。
   → 经验：用 Schema 校验加重试，行号以 Diff 中的实际行为准做二次校验，校验不过的评论直接丢弃，而不是硬挂。

与旧办法相比，新办法的结果如何（数据对比）

方案在业务组试点上线 3 个月后，取得了非常直观的量化收益：

通过这个 AI 落地案例，我的收获有哪些

1. AI 落地要先解决“上下文”问题，而不是先解决“模型”问题：直接全量喂代码库行不通，靠 AST 做增量语义裁剪，既省成本又显著降低幻觉，这是整个方案成立的前提。
2. 把“验证”交给系统闭环，AI 输出才算可靠：单测不是模型写完就完事，而是让沙箱跑起来、把报错回传、触发自愈重试，跑不通就不进主干——可信度是流水线“做”出来的，不是模型“说”出来的。
3. 要给 AI 的输出加约束和反馈：限制评论数量、要求证据代码行、收集“忽略”数据反哺 Prompt，用工程手段把噪音压下去，开发者才不会对 AI 评论“免疫”。
4. 控制成本才能规模化：严格的上下文裁剪让单次审查成本压到几分钱，数十人高频迭代的月度成本仅两三百元，投入产出比极高，这也是方案能从小范围试点走向全组推广的关键。

03 AI 报警预分析器：让人从「找信息」变成「复核判断」

用一段话说清楚，我做成了什么

我是某中厂的一名服务开发工程师，团队没有专职 SRE 或运维，开发之外要兼职处理线上问题与监控报警。过去的方式是靠人 + 一组轻量查询面板逐条翻上下文判断，重复机械劳动多、判断依赖个人经验、报警一多还容易漏掉真故障。从约 4 个月前开始，我尝试搭一个轻量的 AI 报警预分析器来辅助完成报警前的上下文补全、误报初筛与紧急度建议，目前中低紧急度报警已经能让我只做复核与处置。

原来怎么做，为什么值得改变？

报警监控这件事在我们团队里没有专门的人盯着：团队没有 SRE，所以它默认落到每个服务开发自己身上，值班时谁写了那一块代码，谁就去盯那块监控、看报警、做初步判断。实际的频率是每隔一两个小时就会主动扫一眼报警面板，确保没有积压的待处理事件；除了主动巡检，遇到部署、压测、上下游发布这些窗口，还会临时再扫得更密一些。

我每天真正在做的事就是盯线上报警监控、再从里面挑出可疑点。一条报警落到 IM 之后，过去典型的处理路径是这样的：

主流程：过去一次报警处理的“收集—判断”循环

真实举例：任务堆积报警的一次判断分支

经验成熟的报警，比如我已经处置过很多次的某种已知模板，从读报到下结论，大概 3 到 5 分钟就能走完一轮。但只要碰到一点变体，依赖不熟、上下游近期有过变更、错误率曲线不典型，时间就会拉到 15 分钟以上，因为要在脑子里重拼一次链路。而这还只是人已经坐在面板前的情形；再算上报落进 IM 之后等值班人看到、以及陌生报警的排队，整体初判常常会拖到 30 分钟以上。

真正麻烦的是「收集信息」这一步。它由两件事组成：一是拉相关指标，二是沿着上下游去关联日志。这两件事看起来简单，做起来却全靠经验：哪些指标该看、哪些依赖该跟、上游刚发的版本要不要纳入判断。一旦漏掉一项，结论就会跑偏，做起来也非常耗时。只要报警一多，光是「收集上下文」就在消耗一个开发整块的心智。

如果不解决这个问题，那么每天我就会有不少时间消耗在这些监控信息的收集和判断上，而这部分工作对业务的价值很低：它不产生新功能，也不解决新问题，只是被反复消耗。

我具体怎样把 AI 用进去？

保留原有链路，加一条并行的 AI 报警预分析器支线

我没有换掉过去那条“指标 → 监控 → 报警 → IM → 人工”的主链路，而是在报警触发的时候，多挂出一条与主链路并行的 AI 报警预分析器支线。

报警触发后，监控系统通过邮件的方式把同一份报警内容接入 AI 报警预分析器。AI 这一侧做的事是一个“先分类、再按场景调技能 / 不命中就直推、再做产出”的过程：

1. 先对报警进行分类。轻量小模型读报警模板 + 关键字段，把它分到不同的报警场景里（例如任务失败、错误率上涨、依赖超时、磁盘水位等）。

2. 命中现有场景 → 调用对应的“信息收集 + 分析”技能，再到指定的数据源去拉指标、看日志、查变更、读上下游。

3. 没命中现有场景 → 直接把报警原文推到 IM，值班人按老办法人工处理；这一路不留在 AI 报警预分析器内部，避免未知场景被错误地“分析掉”。

4. 命中的分析完成之后，AI 输出一个“排查详情页”，里面按结构化字段写明：details（完整分析，含时间线）、summary（< 60 字）、is_false_positive（是 / 否 + 理由）、is_false_positive_confidence（0–1 小数）。

5. 根据“是否误报”决定是否推到 IM：

   • is_false_positive = true 且 is_false_positive_confidence ≥ 中（≥ 0.6） → 不推送，直接归档；
   • 其他情况（包括 false 与低置信度） → 把标题（一句话，含紧急度）和 summary 推到 IM，并在 IM 卡片上挂一个“查看详情”的链接，值班人点进详情页看完整时间线与分析结论。

由于无法命中的场景会直推原文，真紧急的事情绝不会因为 AI 走岔路而漏掉。AI 报警预分析器的存在只是让人不再需要自己再走一遍那条“挨个面板翻上下文”的循环。

这张图只画 AI 报警预分析器这条支线本身，**没有呈现原本的人工处理链路，**这样反而更清楚：所有报警先经过 AI 入口，命中并完成分析的才走详情页 + 误报分流，没命中的直接按原文推送。值班人始终在 IM 那一侧做最终决定。

提示词示例：任务失败报警的提示词（脱敏）

下面这段是“任务失败处理技能”实际跑的一段提示词（脱敏后）。

你是一个"任务失败"问题分析专家。

【任务处理流程】
……（根据实际场景描述业务处理流程：谁发起、经过哪些环节、每个环节的信息源分别来自哪个数据源）

【问题分析流程】
请按照上面的任务处理流程，逐个环节到对应数据源去收集信息（不是面向单条报警凭空分析），收集完成后，**结构化输出到一个"排查详情页"**，字段如下：

- `details`：完整分析，含按时间顺序排列的时间线（[时间][事件][来源] 三列）+ 各环节数据 + 异常日志片段；
- `summary`：一句话凝练（现象 + 关键时间点 + 是否需要紧急处置），< 60 字；
- `is_false_positive`：是否误报（true / false），并附 `reason` 一句话说明判定理由；
- `is_false_positive_confidence`：误报置信度，取值 0–1 之间的小数；建议分级：高 > 0.85、中 0.6–0.85、低 < 0.6。

【输出要求】
- 不要把时间线和分析混在摘要里：时间线和分析只能出现在 `details` 字段下，IM 卡片上只展示 `summary` + `is_false_positive` + `is_false_positive_confidence`；
- 四项字段必须全部输出，缺一不可；
- 不要凭空分析单行报警文本，所有结论必须能追溯到任务处理流程上的某个具体环节。

示意图（提示词内部的“输入 → 输出”对应关系）：

输入

任务处理流程 ……（按场景填）

↓

输出（结构化详情页）

details：含完整时间线 + 各环节数据 + 异常日志 → 只在详情页展示

summary：< 60 字 → 推到 IM

is_false_positive：是 / 否 + 理由 → 决定是否推到 IM

is_false_positive_confidence：0–1 小数 → 决定是否推到 IM（低置信度按真异常处理）

这一段提示词的几个关键设计：

• 不是面向“这条报警”写提示词，而是面向“这一类任务”描述任务处理流程 + 各环节数据源。它让模型按“流程骨架”去数据源拉数据，而不是凭空分析单行报警文本。
• 写清楚任务执行流程，并强制要求“按时间顺序”列出时间线。任务执行流程要让模型理解事情发生的先后顺序，并据此判断哪些事件在前、哪些事件在后，时间线必须严格按时间顺序排列。这是特意做的，模型经常会把“报警发生之后才出现的现象”误认成“报警的原因”，如果不让它明确理解先后顺序，时间线就先乱掉了，分析结论也会跟着错，我会让时间线在最终输出前显式排序一次。
• 强制按结构化字段输出：IM 推送只看 summary + is_false_positive + is_false_positive_confidence，不把 details 推到 IM，时间线和分析都只待在 details 里，避免 IM 上变成一坨长文。

本章关键论断

关键不在于“用了哪个大模型”，而在于把“找信息 + 初筛”从人身上搬到 AI 上、人只在最后做“复核判断”。AI 报警预分析器不替人下结论；它替人走完那条“挨个面板翻上下文”的循环，把结果整理成结构化详情页，再按 is_false_positive 分流回推到 IM，详情只进详情页。

有没有效果，怎么判断的？

这一章不摆数字，没有对照实验，也没有专门埋点。下表是“自己观察估计 + 经验对比”，含 MTTA / MTTR 这两组数字在内都是我对处理过的报警做的复盘估算，只作参考量级，不要当成正式结论来看。

表格之外，谈三个能直接讲清楚的变化：

• 以前值班人自己翻面板找上下文；现在 AI 报警预分析器把结构化 summary 直接推到 IM，值班人看到报警的瞬间就已经是聚合过的字段组合：误报初判、紧急度、可疑链路。
• 单一来源报警被升级为多源上下文聚合。一条超时报警不再只是“服务 A 报了一个超时”，它附带上下游指标都摆在一起判断，过去孤立的报警变成了可被多人复核的同一份证据。
• 值班人和团队更愿意看 AI 汇总版的报警信息，而不是原始报警消息。原始报警只是一句话 + 时间戳，AI 汇总版有结构化字段、误报初判、时间线和上下文链接，被采纳率高。

上述三点都是观察性结论；后续如果团队愿意，可以尝试跟踪平均处置时长、人工介入率、误报拦截率、MTTA/MTTR、升级准确率这几条指标。

真正变了的是值班这件事的可控性。以前是被报警推着走，节奏完全跟着告警来，现在是 AI 先把不紧急的剪掉，把不熟悉的环节先补全，值班人在它的基础上做判断。

哪里不好用，踩过什么坑？

这套系统跑到现在，影响最大的是下面两个坑。如果你也想照着搭，重点关注这两处。

坑一：让 AI 把分析做“全”，反而拖慢了报警链路

最初我把分析逻辑堆得很大：分类、调 LLM、归一化、出摘要、出时间线，全部串在一条调用链上。结果一条报警从产生到进 IM 要 1 分多钟，值班人开始抱怨“AI 慢”，不是它给的内容不好，而是它塞在了 IM 推送之前。

报警对时效性的要求压倒一切。“分析得更全”明明是好事，但值班人需要先知道“出了什么事”本身就要快，细节可以晚一点。

后期我加了约束：

• 把分析拆成快 / 慢两条链路：高敏字段走“快链路”（轻量小模型 + 规则引擎，秒级），时间线与复杂关联走“慢链路”（异步补充，绝不阻塞 IM 推送）。
• 主链路的端到端设了上限，超过即降级。
• 分类、字段抽取、摘要分头跑、互不阻塞，不让一个大模型串行做所有事。

坑二：AI 全栈故障时，报警跟着停摆

有一回 AI 报警预分析器的下游数据源抖动了一阵，整个分析链路卡住，不仅没有摘要，连原文都没进 IM。值班人盯着一个半小时没动静的 IM 频道，以为系统彻底没报警了。

AI 是辅助层，不是替代层。AI 推不出来的时候，报警必须照样到 IM，不能因为 AI 一坏就一起坏。

后期我加了约束：

• 兜底链路单独跑通：监控到报警之后，原文先推 IM，AI 摘要是叠加层，推不到就只是回到“原始报警”那一条。
• AI 设超时降级：超过阈值仍未出结果，原文落 IM + 一行标注 “AI 分析不可用”，方便追溯但不影响当下处置。
• 兜底链路单独演练，定期确认它在主链路故障时仍能工作。

这两个坑的共同点是：它们都不是“AI 不够聪明”的问题，而是“AI 不能成为主链路的前提”的问题。把这条记在心上，比单独追“准确率”更重要。

如果你也想做类似的事情，可以从哪里开始？

这套方法的边界宽：小团队或中型团队的 7×24 值班都适用，但起点建议放在“小型 + 高频误报模板”上，最容易见到效果。

第一次尝试，建议从一类高频误报 / 重复模板报警开始跑。这一类报警最消耗值班精力，场景小、变量少，提示词与规则都更好调；先覆盖 3–5 类典型场景，肉眼能识别的“高频 + 高消耗”即可。

开做之前只需要做三件事：

1. 梳理这张服务的“任务处理流程 + 信息源”（谁发起、经过哪些环节、各环节的数据从哪里取），并据此写提示词。这是 AI 不在脑子里凭空分析的前提。
2. 定义结构化产出字段（details / summary / is_false_positive / is_false_positive_confidence），让“值班人看什么、AI 推什么”有边界。
3. 搭好兜底 + 降级：原文先推 IM，AI 推不到就降级。

场景库不要想着自动学习，刚开始的几个场景全靠人加，新场景也是靠值班人复盘发现“这条 AI 没分到现有场景、走了原文推送”，再补一条进场景库。不会自动生长的事实一开始就要接受。

如果一时搭不出完整的排查分析工具，**可以让 AI 在本地直接对着代码跑一遍分析流程再总结，**把相关服务的源码、最近一次发布差异、出错堆栈一起丢进本地 AI 工具，让它按“分析流程”走一遍给出时间线与初判；这样不需要一开始就建完整的“详情页 + 邮件推送 + 误报分流”系统，也能先看到 AI 在这套任务上的“裸输出”长什么样。确认效果后再把这一套工程化。

遇到这些情况，需要人工介入，或者暂时不适用：

• 涉及支付链路 / 高敏字段的 P0 / P1 报警，永远由人拍板，不要让 AI 直接决定是否升级。
• 大促、活动期间，自动归类与紧急度判定可能因业务放量而失效；提前降级到“原文推送”。
• 报警量 < 10 条/天的项目，价值不大；这套方法针对的是“值班被报警推着走”那类场景。

今晚就可以做的一件小事：先在值班群里跑通一条兜底报警，把“原文 5 秒内必须落到 IM，AI 摘要推不到就降级”作为最小可用版本。

04 告别人肉排查：AI Agent 打通排查全链路，让经验一键沉淀、自动复用

案例名称

「问题排查小助手」：用 AI Agent 打通研发线上问题排查全链路，让排查经验一键沉淀、自动复用。

案例简介

我在研发团队，负责线上问题排查。

日常最常见的场景是：客服或运营甩过来一条反馈「这个页面打不开 / 这个订单查不到」，附一个 URL 和问题现象，我要去定位根因——这个 URL 属于几十个微服务里的哪个项目？对应日志在哪里？是不是配置错了？是不是某台机器有问题？

我们系统链路上有多套内部平台（项目定位、SLS 日志、配置中心、机器信息），排查一个问题要把这几套系统挨个走一遍。我把 AI 大模型（可切换 DeepSeek / 通义千问）接到这些内部系统上，做了「问题排查小助手」，让它代替人去查、去分析，并把每次排查结论一键沉淀成结构化案例，通过 RAG 复用。

之前的老方案是什么，存在什么问题

之前是纯人肉排查，全靠「问老人 + 翻平台 + 凭经验猜」：

1. 先认项目：拿到 URL 先看域名和路径，猜是几个可能的服务；猜不出来就在群里喊「谁知道 xxx 这个接口是哪个服务的？」，等老同事回。
2. 再找日志：登日志平台，选环境、选时间范围、填关键字搜，关键字不对就换词再搜，来回试。
3. 查配置和机器：日志看不出结论，再去配置中心对照配置、看机器状态，又是一套新平台。
4. 自己分析根因：信息都在脑子里，靠经验判断，最后在群里口头同步结论。
5. 结束即结束：问题解决了就翻篇，过程不落文档，最多在聊天记录里留几句。

这套方式的问题：

• 慢，且大部分时间不是花在思考上，一个问题动辄几十分钟甚至半天，大头是机械查找动作。
• 强依赖个人经验，新人几乎没法独立排查，老人脑子里有「URL → 服务 → 日志在哪查」的映射表，老人一休假问题就卡住。
• 排查质量不稳定，关键字没试对、时间范围选错，就可能漏掉根因，得出「没找到异常」的错误结论。
• 上下文切换成本极高，同时开 N 个平台+聊天窗口，信息靠人脑拼接，容易丢信息。
• 经验零沉淀，排查完没人写 wiki，「写完即埋」，下个人从头走一遍。
• 高峰期响应不了，能排查的人就那几个，得排队等。

如何用 AI 解决

工具与技术：LangChain4j + Spring Boot 3.5（后端编排）、大模型可切换设计（DeepSeek / 通义千问 qwen-max，改环境变量秒切）、MCP 工具接入（把内部系统封装成 project-finder 定位项目 / sls-logs 查日志 / config 查配置 / nodes 查机器）、DashScope text-embedding-v4 做 RAG 检索、Vue 3 + Vite 前端 SSE 流式输出。

整体思路：不是让 AI「答」，而是让 AI「查」。 大模型本身不知道内部线上情况，光靠聊天只能给出通用猜测；真正有价值的是把 AI 变成能操作内部系统的「执行者」。

下面是关键步骤：

1. 入口极简：用户只需输入「URL + 问题现象 + 发生时间/环境」，不填任何技术字段。
2. 工具化内部系统（最关键一步）：通过 MCP 把项目定位、日志、配置、机器查询封装成标准工具暴露给模型，AI 才从「只能聊天」变成「能动手查」。
3. 让模型自主编排排查链路：不写死流程，靠 system prompt 约束排查顺序和边界，由模型判断该调哪个工具、要不要追加查证，遇到非常规问题也能自己调整策略。
4. 过程流式可见：每次工具调用、查到什么、中间结论都实时推给前端，用户能看到它在干活，出问题时一眼看出卡在哪——这是建立信任的前提。
5. 一键沉淀 + RAG 复用：排查结束点一下「保存到知识库」，自动生成结构化案例（问题现象/定位过程/根因/结论）；后续同类问题 RAG 先检索历史案例，命中就直接给出上次的根因。
6. 多供应商可切换 + 降级设计：供应商不稳定时可秒切；embedding 不可用时 RAG 降级为空结果，对话主链路不受影响。

过程中踩过的坑

SSE 流式输出被 Nginx 缓冲，页面一直转圈（排查类场景工具调用接近分钟级，加上缓冲用户以为卡死）

处理方式：反向代理配 proxy_buffering off、proxy_cache off，proxy_read_timeout / proxy_send_timeout 调到 600s。凡是流式 AI 应用走反向代理，这两条是必查项。

JDK 版本坑

处理方式：编译报「未结束的字符串文字」，实为 shell 默认使用 Java 8，项目用了 text block/record 需要 JDK 21。AI 相关框架普遍要求高版本 JDK，部署前先确认运行环境。

RAG 依赖的外部 API Key 没配会拖垮主链路

处理方式：embedding 不可用时降级为空结果 + 明确提示，保证对话主链路始终可用。AI 应用里每个外部依赖都要有降级路径。

内网排查场景主动关掉 web-search

处理方式：开着外网搜索，模型会拿公开资料「补充」内网问题的结论，反而干扰判断。内网场景要让模型只基于内部工具的证据说话。

黑盒等待 = 没人敢用

处理方式：早期版本只给最终结论，中间几十秒转圈，同事用完一次就不来了；改成每步工具调用、中间结论实时流式展示后使用率才上来。过程可见不是锦上添花，是信任的前提。

沉淀功能超过一步就没人用

处理方式：一开始想让同事手工填案例模板几乎没人填；改成排查完点一下自动生成结构化案例，沉淀才能跑起来。

与旧办法相比，新办法的结果如何（数据对比）

• 排查会话：已产生 20 条完整排查会话记录（系统自动留存，真实使用 20 次以上，不是 Demo）。
• 知识沉淀：从 0 到 4 个结构化案例（之前 wiki 几乎没人写），包括「接口无社群渠道幂等 → 同家庭重复创建学生」（AI 顺着日志查出的真实代码缺陷）、「内部交易号订单查询」「学生列表权限过滤逻辑」等。
• 使用门槛：排查入口从「N 个内部平台 + 找人确认」降到「1 个输入框 + 3 个字段」（URL + 现象 + 时间/环境）。
• 排查耗时：从原来的约 30～60 分钟/一个问题降到 5～10 分钟，人效提升约 70%～80%（这几个数字是体感估算，不是按统一口径的统计）。

变化描述（无硬数据但很明显）：新人能独立排查、不再卡在起步；排查质量变稳定（工具调用和排查顺序标准化，很少再出现「关键字没试对所以没找到异常」的假阴性）；经验终于能留下（同类问题第二次出现基本秒级给出结论）；排查过程可见、可追溯；不再强依赖个别人，高峰期不用排队等「会查的人」。

通过这个 AI 落地案例，我的收获有哪些

先打通工具，再谈模型和 prompt：内部系统接不进来，AI 就只是「懂技术术语的聊天窗口」，落地价值为零；工具打通之后，同样的模型立刻能干活。选型顺序应该是：哪些系统能被 AI 调用 → 如何工具化 → 再选模型和写 prompt。

别把 AI 当搜索引擎，把它当执行者：让 AI 出结论容易，让它按业务链路一步步取证、并基于证据说话才难。system prompt 里要严格约束排查边界和「没有证据不许下结论」，否则幻觉会直接变成错误的排查结论，比不用 AI 还糟。

不要把命运绑在单一模型上：模型供应商做成环境变量可切换，任一供应商限流、涨价、不稳定，改一个环境变量就能切走。

密钥管理从第一天就规范：AI 应用天然接触大量内部系统凭据，配置文件不进 git、权限设 600、走环境变量注入。

05 我用 Claude Code 把 Oncall 排查从半天压到半小时

我做成了什么？

我负责 SaaS 平台稳定性，日常需要轮值 oncall。过去采用“人在 kubectl、Grafana、日志平台等系统之间来回切换”的方式，主要问题是链路长、系统多、跨云厂商没有统一入口，几千个业务应用的配置没人全都熟，一个长链路问题平均要耗半天。

从 2026 年 3 月开始，我尝试用 Claude Code 加 MCP 把 Prometheus、EKS、ClickHouse 日志、Cloudflare、飞书等系统接进来，并把排查 SOP 写成 Skill，让 Agent 代替人去跨系统取证据、对代码、查配置。经过半年多、几十次真实排查的使用，目前的结果是长链路问题平均定位时间缩到 0.5 小时以内，陌生组件的配置分析从人工半天缩到十几分钟；其中仍需人工完成的是根因判断、变更执行和对业务影响的评估。

为什么需要改变？

这项任务由谁完成，多久一次：SRE 轮值 oncall，告警群或业务方随时抛问题，平均每天都有需要跨系统排查的事。

原来的流程：

1. 收到问题后先猜方向，打开 Grafana 翻几张看板，再 kubectl describe / kubectl logs 逐个看 Pod。
2. 去日志平台按时间段捞日志，去 Cloudflare 后台查边缘侧有没有异常。
3. 涉及组件行为的问题，要去翻组件的参数、ConfigMap，再对着官方文档或源码猜它为什么这么做。
4. 有些还要拉业务团队、DBA 一起看代码和数据库。

最麻烦的一步：不是某一个系统难查，而是线索散在五六个系统里，没有统一入口。会有不同的云厂商，会经过 Cloudflare、自研外部网关、应用内部网关、两千多个应用、代理层、公共中间件，再到 HPA / KEDA / Cluster Autoscaler 这些平台组件。每一层都有自己的查询方式和口径，人要在脑子里把它们拼成一条时间线。更要命的是对不熟的组件没办法快速建立认知：一个平时不碰的扩缩容组件出了问题，光是把它的几十个启动参数、默认值和实际配置对一遍，就要半天。

一次具体任务：一个不太熟悉的平台组件故障引发了单个集群 30% 节点异常。按经验估计，要读组件文档、对线上配置、捞故障时段的日志、再看源码确认行为，至少 2 天才能给出可信的根因。

不解决的影响：故障定位慢直接拉长 MTTR；排查依赖少数几个熟悉全链路的老人，新人上 oncall 只能转派；每次排查的思路留在聊天记录里，下次同类问题还是从头来。

具体怎样把 AI 用进去？

先搭好“眼睛”和“规矩”：接入全部系统，再把 SOP 写成 Skill

这一部分做在排查之前，是后面所有案例的基础。

接入层（MCP + CLI），全部用只读账号：

规矩层（CLAUDE.md）：精简且必须的内容，如不同云环境等特定认证，说明基础设施等不同如何做处理，一些内部特定信息如何做关联，Agent 每次对话自动读到，不用人反复交代，也不会连错环境。

SOP 层（Skill）：把排查方法固化成 Skill 和配套脚本，目前 16 个。和问题定位直接相关的有：

• 故障分层排查定位规范：把一次请求经过的链路分成 L0～L7 七层加观测、变更两条贯穿层，每层用黄金四指标判“请求到我这一层是否正常进、正常出”，排查顺序自上而下二分，目标 5 分钟确定坏在哪一层，15 分钟定位到组件。
• 巡检流程：一条命令拉出集群 86 项健康快照，和 1 小时前、7 天前对比给红黄绿结论，红黄项自动下钻到节点组 / HPA / Pod / 服务。

护栏：所有 MCP 和账号只读，settings 里禁止写操作，生产集群的变更只允许人审核后经封装预定义的工具做变更操作。Agent 可以放开查，但不能直接改东西。

一次有代表性的排查：陌生扩缩容组件引发集群异常

下面按发生顺序写，每一步都交代输入、操作、输出、人工处理、下一步。

第一步：定影响面。 先准备了告警群里的原始消息和大致时间段，交给 Claude Code，要求它按分层规范先确定“坏在哪一层”。它调用 stability-watch 和 Prometheus MCP，给出的结果是：入口链路 RED 指标正常，异常集中在 L6 容器平台层，节点组的节点数和 Pending Pod 数在故障时段明显偏离 7 天基线。确认了这个方向和告警现象一致，排除了应用发布和边缘侧的嫌疑，于是让它往平台组件下钻。

第二步：把陌生组件的配置一次性读透。 Agent 根据组件名，列出这个组件在线上的全部启动参数、ConfigMap 和相关 CRD 配置，并和官方默认值逐项对比，标出被显式修改过的项。它通过 EKS MCP / kubectl 读到 Deployment 的 args 和 ConfigMap，用十几分钟整理出一张“参数 → 线上值 → 默认值 → 作用”的表。发现其中几个参数的组合和我们对它的预期不一致，出现少量节点异常的时候，自动扩缩容就不工作了。一个组件意外异常时，整个集群失去自愈能力。于是把这几项标记为重点，进入下一步。这一步人工做至少要半天，因为要边查文档边对配置。

第三步：读组件源码，确认它在这组配置下到底会怎么做。 Agent 拉取组件对应版本的源码，围绕上一步标出的参数，找到解析和使用这些参数的代码路径，解释在当前配置组合下的实际行为。并指出了会打出的日志关键字。

第四步：用故障时段的日志反过来验证。 Agent 按上一步给出的日志关键字，捞故障时段这个组件的日志，看代码里的那条异常分支有没有真的被走到。它从组件日志里匹配到了对应的记录，时间点和集群异常开始的时间吻合。到这里证据链闭合：配置冲突 → 代码分支 → 故障时段日志 → 集群现象。

第五步：还原现场做配置验证。 在非生产环境按线上配置还原了这个组件，由 Agent 生成对照用的两组配置和观察指标，人来执行和观察。结果是按线上配置能复现异常，改掉冲突项后恢复预期行为。

第六步：输出报告。 Agent 把以上证据链整理成一份带参数表、代码位置、日志片段、验证结果和修改建议的文档，我补充了业务影响和变更计划后上传飞书知识库。整个过程半天，原本的预期是 2 天。

如何判断效果？

补充说明：

• 这不是一次尝试，是持续使用。从 2026 年上半年至今，本仓库已沉淀 16 个 Skill，排查类报告（OOM 分析、Pod 重启、CDN 性能审计、CA 行为分析、5xx 错误、ingress 路由异常等）持续积累。
• 没有全链路经验的人也能用同一套 Skill 和提示词走完排查，因为口径、账号、分层规则都在 CLAUDE.md 和 Skill 里，不在人脑子里。

哪里不好用，我踩过的坑？

1. 最初的方法为什么没奏效：直接问 Agent “为什么异常”。 第一版没有分层规范，直接把现象丢给 Agent，它会同时查很多东西，给出一个覆盖面很广但没有重点的回答，看起来像结论，其实是猜测。改成“先定层再下钻”之后才稳定。教训是：SOP 要先写给 AI，再让 AI 用。
2. AI 出过的错：数据口径错，PromQL 语法完全正确。 用 rate[1d] 算日均 QPS，Pod 重建导致计数器重置，结果虚高 2～6 倍；request 没按 Pod phase 过滤，已完成 Job 被计入，装箱率算出 143%。这类错误靠“看起来不合理”的数字发现，比如装箱率超过 100%。处理方式是每个坑都写回 Skill 或 CLAUDE.md，让它变成 AI 下次的默认行为。
3. 为了稳定使用加的约束。

• 全部账号只读，settings 禁写；生产变更只允许人审核后执行生成好的命令。
• CLAUDE.md 记录集群与认证方式的对应关系，不写 AI 会猜，还可能连错环境。
• 判定逻辑写进脚本不交给模型自由发挥，保证同一个问题两次跑结果一致。

4. 仍选择人工处理的情况。

涉及业务语义判断的问题、生产变更，Agent 给证据链和方案，人做决定。

如果你也想做类似的事情，可以从哪里开始？

这个方法适合负责多系统、长链路线上环境的工程师，在各系统有可查询的 API 或 CLI、且能申请到账号的条件下使用。开始前需要准备：Claude Code、各系统的只读凭证、一份写清集群与账号对应关系的 CLAUDE.md。第一次尝试，建议先拿“某个 Pod 重启了，查原因”这样的小任务练习：接一个 Prometheus MCP 和只读 kubectl 就够，跑通后把这条路径写成第一个 Skill。遇到需要进节点或容器、需要业务判断、需要变更生产的情况时，需要人工介入；系统没有可编程接口的，暂时不适用。

一个可直接执行的起点顺序：

1. 配 Prometheus MCP 和只读 kubectl，写 CLAUDE.md 里的集群账号表。
2. 用一次真实的小问题（Pod 重启、HPA 卡顶）走一遍交互式排查。
3. 把这次排查的步骤、PromQL、口径坑写成 SKILL.md。
4. 下一次同类问题直接用 Skill 触发，看是否不需要人补充上下文。
5. 跑通后再接日志、边缘、协作工具，补分层排查规范。

最后想分享的话

Agent 在排查里最有价值的不是“它比人懂”，而是它能不知疲倦地把五六个系统的证据拉到同一条时间线上，并且每一步都留痕。人该做的是定方向、挑可疑项、判断证据链有没有闭合。“AI 负责调查，人负责判断”，这个分工定下来，新人和老人用的就是同一套流程。

06 装得满 ≠ 用得好：一条让节点数降 46％ 的资源优化流水线

案例简介

我新到一家 SaaS 平台公司做 SRE，负责生产 K8s 集群的资源与成本，涉及数千个应用。集群当时“装得满、用得少”：按 request 看装箱率超过 90%，真实 CPU 利用率却只有 10%。我用 Claude Code、Skills、Prometheus MCP 和只读 kubectl 搭了一条资源优化流水线，把取数、筛选、出方案、生成命令分开，再由人评审、灰度执行并验证。AI 负责编排和解释，计算规则放进脚本，生产变更由人控制。

以前怎样调资源

原来要在 Grafana 或命令行里逐个应用查用量，凭经验判断 request、limit 和 HPA 应该怎样调整，再手写 kubectl patch。应用一多，查询、计算和命令之间就很难保持一致。

• 一次调整上百个应用，一轮要花半天甚至更久。大部分时间消耗在重复查询和整理上，还容易漏查或算错。
• 筛选条件也经常变：只看某个节点组、排除核心应用，或者只看副本数大于 3 的应用。过去每换一组条件，都要重新整理数据或修改查询和处理逻辑，讨论方案的成本很高。
• 调整之后缺少系统性回看，配置又会随业务变化重新膨胀；HPA 震荡、卡在最大副本等问题，也只能偶然发现。问题不只是这次能否把 request 调小，而是能否反复跑同一条分析和验证流程。

这一轮优化具体怎样做

准备阶段，我让 Claude Code 参与编写 Skill 和配套脚本。Prometheus MCP 提供监控数据，kubectl 用只读账号检查现状；执行变更时，由人工切换到有权限的账号。这里没有让 Agent 直接取得生产写权限。

第一步，取数与判断分开。

resource-metrics-fetch 按 1 分钟粒度拉取各 Deployment 的数据，包括 P95 与均值用量、request/limit、Pod 数、HPA 阈值、优先级和节点组，输出 CSV。先留下同一批基础数据，后面改条件时不必把慢查询再跑一遍。

第二步，用自然语言缩小候选范围。

我可以提出“只看某节点组、用量低于 request 30% 的非核心应用”等条件，由 k8s-resource-filter 处理筛选。输出是候选清单，还不是执行清单；哪些应用可以进入这一轮，需要结合优先级和业务约束评审。

第三步，按固定规则形成方案。

k8s-resource-adjust 根据资源配额规则和目标利用率计算新的 request、HPA 配置及预期 Pod 数，生成方案表。规则写在脚本里，模型负责解释方案，避免同一份输入因为模型措辞变化而得到不同计算结果。

request 和 HPA 需要一起看。按 CPU 利用率伸缩时，利用率与 CPU request 有关；request 下调，可能改变相同负载下的伸缩行为。因此，“request 下降多少”不能直接等同于“节点就能减少多少”，还要检查副本变化和实际资源需求。

第四步，评审后生成变更和回滚命令。

k8s-resource-generate 为方案生成 kubectl patch，并附对应 rollback 命令。人核对目标集群、命名空间、应用和变更值后，再进入执行阶段。命令能生成，不代表已经具备执行条件。

第五步，分级灰度并回看。

先低用量应用，再普通应用，核心应用最后。每批执行后，AI 根据变更清单检查 Pod 就绪、重启、HPA、request 生效和流量情况，人判断是否继续下一批。变更清单也成为验证范围，避免改完一批后只看整组平均值，漏掉个别应用异常。

结果是什么，口径怎样理解

这一轮调整后，目标节点组日均节点数下降 46%。扣除调整前已有的自然下降趋势后，我估算约九成节点降幅与本轮调整有关。这是趋势扣除后的归因估算，不是有对照组的因果实验，也不能把 46% 直接写成公司总云账单的降幅。

我还做了一次交叉核对：按 request 下调量折算的节点数，与监控实测下降量偏差小于 5%。两种口径接近，支持这一轮调整确实释放了资源；但它不能单独证明所有业务场景下都没有性能影响，仍要以灰度后的应用与流量检查为准。

分析环节从小时级缩到分钟级，是这条流水线带来的直接变化。这里指取数、筛选和形成方案的分析环节，不把尚未明确计入的人工评审、灰度观察和回滚验证时间一并算作“分钟级完成”。

相比一次性降配，更可复用的变化是筛选条件能在对话里调整，基础数据不用重复抓取，方案和命令也能对应起来。它让多看几轮方案变得容易，同时把生产执行留在明确的人工检查点。

这条流水线踩过什么坑

最初把所有工作塞进一个大 Skill，取数慢，筛选和方案却要反复改，每次重跑都浪费时间。拆成取数、筛选、出方案等阶段后，慢的部分只跑一次，需要讨论的部分可以快速重来。阶段之间保留 CSV 和方案表，也更方便复核。

另一条经验是，计算规则必须落到脚本。AI 可以理解筛选意图、组织工具和解释结果，但不能靠对话临时心算配额。为了让别人复现，规则、输入数据和输出方案都需要能对应，而不能只剩下一段“建议下调”的文字。

批量调整还必须有分级灰度和回滚准备。低用量只是进入评审的线索，不是可以无条件降配的证明。遇到业务约束不清、监控样本不足或灰度结果异常时，应由人暂停处理，先补足判断依据，再决定是否继续。

如果你也想做类似的事情，可以从哪里开始？

先选一个节点组，导出一批非核心应用的用量、request/limit、Pod 数和 HPA 配置，只做分析，不急着生成生产变更。把“取数”和“按条件筛选”跑通后，选几项人工核算，确认监控口径和脚本计算一致。

再把资源配额规则写成可复核脚本，输出候选方案、对应 patch 和 rollback。先在测试环境核对命令，再挑少量应用灰度；每批观察什么、什么情况下停止，提前写进执行清单，避免执行到一半才临时讨论。

对我来说，AI 的价值是把原来分散的查询、筛选、计算和命令生成串起来。规则决定方案是否一致，人工评审与灰度验证决定方案能否进入生产，两者缺一不可。

07 为非研发同学搭建 Vibe Coding 工作台：让所有人都可以写代码、发布页面

本文从研发建设者视角，记录如何为非研发同学准备真实可用的 AI 页面工作台。依据项目代码与历史记录整理；提示词为复用示例，未统计非研发同学独立交付次数和节省工时。

我做成了什么：为非研发同学搭一套能接真实业务的工作台

我是 Alan，一名 AI 工程师。我希望非研发同学能用自然语言与 AI 协作制作页面，同时沿用公司的登录、接口和发布体系。从 2026 年 9 月开始，我们搭建极客时间 Space 工作台，用 AI 辅助实现页面和工程能力。重点是把公司子域名 HTTPS、本地接口代理、服务端渲染时的身份传递和上线流程封装好。非研发同学可以围绕内容、布局和交互持续修改；研发负责环境、权限与技术边界，业务同学仍负责内容审核、效果验收和发布决定。

为什么一个能预览的页面还不够？

设想非研发同学用 AI 做好一个专题页：浏览器能打开，接口却取不到预期数据；官网明明已登录，本地仍显示访客。即使浏览器里的交互正常，第一次打开页面时，服务端拿到的又可能是另一种状态。这些问题会直接打断非研发同学的自然语言迭代，让每一次修改重新依赖研发排查。

这个项目保留 Nuxt 的服务端渲染（SSR），让公开正文、标题和分享元信息可以随首个 HTML 返回，为首屏和 SEO 提供基础。代价是要同时处理浏览器与 Node 两个执行环境。域名、证书、跨域、Cookie 和公司网关，都会影响 AI 生成的页面是否真正可用。

因此，项目建设围绕一个场景展开：让非研发同学自己的电脑运行本地页面，又能在既有权限内使用真实业务能力，并把确认后的代码交付到公司仓库。

与 AI 协作，补齐四个工程断点

搭建这套工作台时，使用 AI 作为开发协作者，先提供非研发同学的使用目标、现有 SPA 源码，以及公司登录、接口和部署规则，再分步推进实现。AI 负责阅读参考工程、提出方案、修改代码，并运行检查和调试；我负责补充业务背景、明确改动边界，以及验收实际使用体验。

我们根据运行结果持续调整方案。遇到本地登录、启动配置或页面预览问题时，我把具体表现和使用要求反馈给 AI，由它继续定位、修正并验证，再将结果沉淀为工具、公共封装和项目说明。以下四个工程断点，是这一协作过程的主要落点。

在非研发同学电脑上提供公司子域名的 HTTPS 入口

这里有四件不同的事。共享登录 Cookie 属于公司域名，浏览器不会把它交给 localhost；Secure Cookie 又需要安全连接；浏览器直连接口会遇到跨域限制；普通用户启动服务还要避开系统端口与已有软件。

我们把入口固定为一个伪造的线上不存在的域名，但未在跨域的限制中，用 hosts 将这个公司子域名解析到本机 127.0.0.3。页面仍运行在非研发同学电脑上，浏览器则按已有域名规则携带适用的共享 Cookie。本机独立生成 CA 和域名证书，让 HTTPS 通过正常信任校验，证书私钥不进入仓库。

Nuxt 以普通用户监听 3100。macOS 用 PF、Windows 用 portproxy，把专用回环地址的 443 转到 3100；它统一访问、回跳和热更新入口。Cookie 本身不按端口隔离，不能把默认端口当成共享登录成立的原因。开发页面的 API 请求再交给 Nuxt 同源代理，由服务端访问已登记的上游，解决浏览器的本地跨域问题。

这些配置被做成随仓库分发的 Go 环境助手。非研发同学说“帮我启动项目”，AI 执行预检与启动；首次系统配置由本人授权，日常就绪后跳过授权。助手提供检查和卸载，遇到冲突明确失败，不擅自停掉其他服务。专用的 .3 地址也避开了其他项目使用的回环入口。

让开发登录态贯穿 SSR 请求与换票响应

有了本地域名，浏览器能把 Cookie 带到 Nuxt，但 Node 发起的接口请求不会自动继承浏览器的 Cookie 仓库。若只解决前端请求，首个 HTML 仍可能按访客渲染；账户服务返回的新 Cookie，也不会自动穿过内部调用回到浏览器。

我们把原始页面请求保留在 Nitro 的进程内上下文中，取数时只提取允许的共享 Cookie，经公网 HTTPS 交给既有 WAF 判断会话。换票时检查 Cookie 名称和所属域，保留原属性，再显式写回页面响应。身份判断继续由公司的登录体系完成，页面不用实现另一套票据逻辑。

这条链路没有通过前端可伪造的“当前用户 ID”传递可信身份，也不把票据放进页面数据或浏览器存储。请求结果按身份模式区分，相关响应禁止共享缓存。业务页面使用统一取数封装，SSR 和浏览器复用结果，减少每页各写一套会话处理。

材料一｜本地公网模式的页面与接口链路

sequenceDiagram
    participant B as 运营浏览器
    participant N as 本机 Nuxt
    participant U as 公网 WAF 与后端
    Note over B,N: 公司子域名 + 可信 HTTPS；本机 443 转 3100
    B->>N: 首次页面请求，携带共享 Cookie
    N->>U: SSR 取数：HTTPS + Cookie 白名单
    U-->>N: 业务数据，必要时返回换票 Cookie
    N-->>B: SSR HTML，显式回写合规 Set-Cookie
    B->>N: 页面交互：同源 API 请求
    N->>U: 统一封装发起上游请求
    U-->>N: 业务响应
    N-->>B: 同源 API 响应

图示以已在同一浏览器完成官网登录、页面需要 SSR 取数为前提。公开内容可以保留 SSR，账户区域也可以按页面需求在客户端查询；项目中部分阅读页就采用后者。保留 SSR 能力，并不意味着所有页面都必须服务端查询登录，更不等于已有搜索排名增长。

让非研发同学看见一致的访客状态

非研发同学验收未登录文案时，如果只切换界面，接口可能仍带着真实身份。工作台在开发页提供“当前登录态／未登录”切换：仅保存一个不含身份的预览偏好，刷新后让 SSR、Node 和浏览器请求共同执行匿名策略，不发送凭据，也不接受换票。

这不会退出非研发同学的官网账号，切回后可恢复已有会话；生产环境忽略预览偏好。人工能直接检查两种状态，AI 也不用生成假用户或临时登录入口。

把公司能力和交付差异收进公共层

本地与线上也有不同的身份来源：本地走 Cookie、HTTPS 和公网 WAF；线上 SSR 可走可信入口鉴权后的内网身份头。内网服务不负责解析浏览器 Cookie，因此不能只替换接口域名或协议。项目分别管理两条链路，内网校验直接连接的来源；浏览器自报身份无效，缺配置明确失败。

本站页面和代理地址统一处理 /space/ 前缀，后端接口使用已登记的服务地址；分享保留当前站点域名，静态资源与 CDN 配置对应。我们把这些规则交给公共封装，将构建接入公司 GitLab CI：确认发布后推送主分支，自动构建部署；静态资源上传路径与 CDN 配置对应，服务端产物保留在运行镜像中。非研发同学用同一套页面代码继续迭代，研发维护这些环境差异。

材料二｜给 AI 的工程约束示例

先读项目规范和现有账户、接口封装。保持公开内容的 SSR，不用整页 ClientOnly 绕过问题。业务请求沿用公共封装，登录仍外跳现有账户页。核对浏览器与 Node、会话与匿名四种组合，再说明手机适配和未验证项。先完成本地预览，收到明确指令后发布。

AI 可以据此生成实现、补充检查和修复；研发核对身份来源与部署假设。约束留在 AGENTS.md 和路由说明中，非研发同学用法留在 VIBE_CODING.md，下一次协作可继续复用。

效果如何判断：先看链路和交付物

当前可核实的变化，是这些断点已有公共实现和验收入口。

验收脚本覆盖浏览器／Node × 会话／匿名的组合，并检查三个站点 Host 下的 SSR 内容、分享元信息、样式和敏感配置隔离。它们证明项目有相应检查设计，本次写作没有重跑测试。

知识库提供了具体应用：9 篇“AI 研发效能”正文和一个交流群引导页复用现有阅读组件，再加入聚合入口。2026 年 10 月 15—16 日记录包含 62 项自动化测试、4 种冒烟模式及桌面和手机视口检查通过；未完成真机、软键盘与 App 验证。它说明底座已有实际页面承接，但没有非研发同学独立交付率、完整工时或成本对照，暂不能计算效率收益。

落到使用：非研发同事上线一个新页面只需几步

前面衡量的是底座能力；落到使用上，平台的价值在于把“上线一个新页面”的一系列动作，压缩成几句自然语言。平台就绪后，非研发同事要做的事分为两类：一次性的首次准备，和每次上线新页面都会重复的日常操作。

• **首次准备，只需一次。**连接公司网络、配置本机 Git 权限、把项目克隆到本机——这些步骤都写进了快速上手文档，代理、DNS、SSH 的常见问题也有现成说明。之后对 AI 说一句“帮我启动项目”，它就会自动检查依赖、唤起本地服务，并打开公司子域名的 HTTPS 预览页；首次系统授权由本人在终端确认，日常再次启动可直接跳过。
• **日常修改，只用自然语言。**用 AI 编程工具打开项目目录，描述想要的效果，例如“新建一个页面，路径 /space/xxx，包含顶部大图、报名表单和提交按钮”。AI 会按项目规范自动同步主分支、创建开发分支并实现页面；保存后浏览器实时预览，继续对话即可微调布局、文案与交互。
• **上线之前，只需做业务判断。**手机适配、接口状态等交付要求，由 AI 逐项检查并说明已验证与未验证项；涉及个人信息、订单或正式数据修改，先请研发确认方案。确认无误后，对 AI 说“按规范合并到主分支并推送到远端发布”，自检通过即合并推送，公司流水线自动构建部署，在工作群收到发布成功通知，页面即上线。

最近一段时间，这套流程已被非研发同事实际跑通：从克隆仓库、配置权限开始，陆续完成知识库新页面的制作、全文标题规范的批量调整和案例图文内容的补充；页面从提出需求到本地预览，不再等待研发排期，研发只在环境与权限的边界处介入，并提供必要的专业支撑。同时，对业务团队来说，内容、审核与发布这些业务判断，仍然完整地保留在运营侧。

踩坑与边界：把“能运行”继续往前推进

**SSR 还要照顾组件样式与浏览器 SDK。**项目记录了 Naive UI 的兼容处理：旧集成依赖的样式出口不适用于当前 Nuxt，改为每次请求独立收集官方 CSS Render 样式并写入 head。分享 SDK 留在浏览器动态加载，避免服务端执行依赖 window 的代码。正文、元信息和样式都要在初始 HTML 中检查。

**验证失败也需要技术判断。**专题首次冒烟在 AI 工具沙箱内因 EMFILE 中断，调整执行环境后四种模式通过。这个真实记录提醒我们，报错可能来自运行环境，不能直接让 AI 反复改业务代码。

**真实环境仍有明确边界。**本地代理不能代替公司网络、账户权限、生产 CORS 或微信域名授权。项目没有测试与预发站，自动化用隔离数据；涉及订单、支付或正式数据修改，需研发确认。

如果你也想做类似的事情，可以从哪里开始？

这套方法适合有既有账户、接口和发布体系，希望让非研发同学参与页面制作的团队。先选一项小业务，画清浏览器、SSR 和后端各自怎样取得身份；再把域名、证书、代理和取数方式做成可检查的公共能力。

第一轮用一个内容页验证首屏、接口、登录与访客状态，以及手机布局；发布前确认代码能进入公司仓库和流水线。非研发同学日常保留“启动项目—描述修改—查看效果—确认发布”的简单流程。研发每补齐一个可复用的断点，非研发同学与 AI 的下一轮协作就少一项环境判断。

08 从一眼 AI 到一眼惊艳：非开发者的高审美 coding 实践

先用一段话说清楚，我做成了什么

我是一个非技术出身的 AI 开发者，日常需要把产品想法做成能用的网页和功能，不光功能闭环，还得好看。过去主要是把需求交给 AI，做出来再反复改，最麻烦的是功能通了，AI 味还是很重。过去几个月，我持续用 AI 编程工具做产品，也开始用 Obsidian 留下每轮的反馈和判断。现在已经做出了发布后被人夸好看的东西，也逐渐打磨出 11 个节点和配套标准卡片。其中业务取舍、审美判断和最终验收，还是我来做。

原来怎么做，为什么值得改变？

这项任务由谁完成，多久发生一次？

主要是我和 AI 一起完成。我提需求、判断效果，AI 做方案、页面和实现。过去几个月一直在做，网页、小程序和独立产品都有。它不是固定每周一次的任务，有新模块、新页面或需要改版时，就会再走一轮。

原来的工作流程是什么？

想到需求就交给 AI，等它做出来，我再打开看，哪里不对就继续说。最初先追求功能跑通，后来开始磨文案、布局、交互，一轮轮去 AI 味。磨出满意结果后，再做下一个东西。

最麻烦的是哪一步？是耗时、容易出错，还是质量不稳定？

最麻烦的是反复手搓。比如一个活动页面，按钮、卡片都有，但到处是解释小字，重点不突出，交互也很常规。我得继续指出哪里不对。换一个页面，类似要求又得重新讲，所以既耗精力，质量也依赖我一直盯着。

如果不解决，会产生什么影响？

产品可以一个个做出来，但每次都要从头磨。我希望这次花的精力，下次也能帮上忙。否则做了很多项目，留下了作品，做事的方法却没积累多少。

我具体怎样把 AI 用进去？

这几个月，不管做哪个项目，大致都在经历同一件事：先搞通，再一轮轮去 AI 味，后来开始想，手磨过的东西能不能留下来，下次接着用。下面拿两个很小的页面问题，把这个过程讲具体。11 个节点和标准卡，是在这些实践里逐渐补齐的。

第一步：先做出页面，在实际结果里发现问题

• **你给 AI 提供了什么资料？资料需要怎样整理？**给它页面要解决的问题、已有内容和产品里的参考页面。比如填写嘉宾介绍，既要说明资料怎样共用，也要给它已有表单作样式参考。
• **用了什么工具或模型？你怎样提要求？**用 Codex 等 AI 编程工具。先把页面做出来，再打开看。哪里不对，就对着实际画面继续说，光说“不好看”没用。
• **AI 产出了什么？可以展示一个片段吗？**做出了表单，但把我用来说明资料范围的“本人一份，所有活动共用”，也直接写成了页面文案。
• **你检查、修改或补充了什么？**让它删掉这句说明，共用资料的规则继续保留。输入区域也要对照已有表单，不能只改我刚点名的一句话。
• **这个结果怎样进入后续工作？**继续磨页面，也开始把“AI 味”拆具体：哪些说明没用，哪些样式没对齐，什么地方影响用户操作。

关键材料 1｜实际输入和 AI 初稿

2026 年 10 月 8 日，AI 问嘉宾介绍是一份共用，还是每个活动各一份。我回答：本人一份，所有活动共用。

下面是当时的 AI 稿。这句话被原样放在了嘉宾名字下面。

关键材料 2｜人工修改要求和样式参考

我接着指出：你觉得你这个对吗？

本人一份，所有活动共用，这是废话，去掉

同时给了产品里已有的输入样式作参考：

这张是参考图，和上面那张 AI 初稿一起给它看。我的要求也不只是“删句话”，还包括按已有产品的样式继续磨。

第二步：反复手磨，把去 AI 味落实到具体操作

• **你给 AI 提供了什么资料？资料需要怎样整理？**给它当前页面、具体问题和交互参考。比如用户看活动、展开海报，先看这个动作怎样才顺，再找适合的效果。
• **用了什么工具或模型？你怎样提要求？**继续让 AI 改，也让它去 Obsidian 找交互卡片。有合适的就借，没有就按当前场景做，不为了用卡片硬套。
• **AI 产出了什么？可以展示一个片段吗？**改了海报展开方式。但中间又出现大窗口里海报很小、滚动时慢慢放大的问题，交互本身也还太常规，继续改了多轮。
• **你检查、修改或补充了什么？**我自己打开操作，看展开方向、尺寸、滚动和关闭。技术检查过了，审美上不满意，还是要接着磨。
• **这个结果怎样进入后续工作？**认可的版本留下来，后面开发和验收要对着看。前面磨好的交互和动效，不能到后面又丢了。

关键材料 1｜当时的问题截图和实际反馈

2026 年 10 月 12 日，我对下面这版的反馈是：

交互可以吧。但是这里还有问题，这么大的窗口时，海报变得特别小，然后鼠标滚轮滚动时，它会慢慢放大，咋回事？

关键材料 2｜实际提示词和对应修改结果

后面我又提了一轮要求：

不行，这块海报展示的交互还是太常规了，你看看我们卡片里有没有更好的方案。如果实在不行，就从左上角或左下角向对角线做扩展

AI 检查了几份交互参考，没有直接合适的，就按这次要求做了对角展开，也修正了滚动时尺寸变化的问题。下面是当时测试环境中修改版的原始截图：

两张图可以看到尺寸变化；对角展开的动效，需要实际操作才能看出来。

关键材料 3｜人工验收原话

对这一版海报交互，我后续的反馈是：

这个交互可以

这一轮，是 AI 找参考、改实现和做检查，我实际操作、继续提要求，最后判断这版交互可以了。

第三步：把手磨的东西留下来，进入下一次任务

• **你给 AI 提供了什么资料？资料需要怎样整理？**给它实际对话、我的反馈、被否决的稿和保留下来的结果。原话和来源留着，具体项目的决定与下次还能用的判断分开。
• **用了什么工具或模型？你怎样提要求？**让 AI 在 Obsidian 里整理方法和标准。得说人话，写清什么时候用、怎么做、怎么检查，换一个 AI 也能看懂。
• **AI 产出了什么？可以展示一个片段吗？**逐步整理出了标准卡，也和我一起打磨出了 11 个节点。比如文案卡里就有：“只保留对用户有信息增量的文案；不要给每个模块、标题和按钮配解释小字。”
• **你检查、修改或补充了什么？**看它离开原对话还能不能用。海报从哪个角展开，是那次项目的选择；以后都要结合布局和用户动作判断。已有规则没执行，就补执行，不能什么问题都再加一张卡。
• **这个结果怎样进入后续工作？**新任务开始，让 AI 主动找适用的方法、标准和参考，落实到方案、页面、开发和检查里。用过后再看有没有改善，继续磨原来的方法。这才是我想要的复利。

关键材料 1｜要求沉淀的实际提示词

整理方法时，我说过：

等会，这些难道不应该整理成卡片吗？不然以后怎么调用？

也继续要求：

那这种东西需要根据我们的卡片标准的原则整理成对应的卡片呀 不然你怎么调用啊？

关键材料 2｜沉淀后的文案标准卡

这张卡把反复遇到的废话问题，整理成了适用场景、具体动作和检查方法。下面是这次在 Obsidian 里打开正文后截的图：

关键材料 3｜11 个节点和人工确认分工

现在的流程包括：用户分析、产品功能方案、视觉方案与调研、技术方案、核心方案、可操作 UI 稿、自主开发、功能验收、视觉交互验收、发布上线、复盘与标准回流。

AI 按节点做研究、方案、实现和检查；我确认各阶段的具体成果，做取舍和验收。其中第 7 节点由 AI 按已确认方案自主开发、自查，再提交验收。下面是现行目录的实拍：

有没有效果，我是怎么判断的？

• 这是一次尝试，还是已经持续使用？已经持续做了几个月，多个项目里都会遇到类似问题。11 个节点和卡片是在这个过程中逐步形成的，不能倒过来说，每个早期项目都完整执行了现在这套流程。
• 比较涉及多少次任务？做过多个 Web、小程序模块和独立产品，但还没按统一口径统计可比任务数。现在写的是持续实践中的观察，不是一组严格对照实验。
• 前后的任务难度和质量要求是否接近？不完全接近，项目、范围和工具都会变。能明确说的是，个人做这个事确实省心多了。像我们这种需要创造的，降低这种意义不太大的折磨是挺有必要的。
• 时间节省是否包含人工检查和修改？我还没有可靠的时间节省数字。如果以后比较，会把准备资料、检查、返工和维护方法都算进去。不能 AI 做得快了，我检查和补漏的时间却更多，最后还说提效了。

哪里不好用，我踩过什么坑？

• 最初的方法为什么没有奏效？只说“不好看”“AI 味太重”，要求太模糊；只盯着改当前页面，又留不下能继续用的判断。所以后来我开始把问题说具体，并保留每轮纠正的过程。
• AI 曾经出现什么错误？你怎样发现？说跑通了，实际用又没通；视觉稿磨好了，开发时丢了交互；读了旧标准，仍然出现重复问题。这些都是我打开页面、实际操作和对照原稿时发现的。
• 为了稳定使用，你增加了哪些约束或检查？先看可操作稿，再进入开发；划分成 11 个关键节点，每个节点打磨流程。比如，用户分析层面是第一个节点，那必须要经过某些调研的方法调研，然后划分目标用户、做分层、用户视角如何、分析用户场景、洞察问题是什么，这些都磨成标准化的输出；一些被我反馈过的点，做成标准卡片，逐个卡片打磨。
• 什么情况下，你仍然选择人工处理？业务取舍、审美判断和最终验收；或者想做出差异化的能力；

如果你也想做类似的事情，可以从哪里开始？

这个方法适合什么样的人，在什么条件下使用？

适合已经用 AI 做出一些页面，但总觉得不满意、需要反复修改的人。最好拿真实任务练，有实际使用场景，也愿意自己看结果、提反馈。

开始前需要准备什么？

准备当前需求、已有页面或合适参考，以及清楚的完成条件。先把已有材料用起来，不用一上来就建一大套知识库。

还有，需要做好心态上的准备，这不是搞两天就通了的。需要有螺旋上升，不断迭代的心态。

第一次尝试，建议先拿什么样的小任务练习？

别太复杂，也别过于简单。最好是一个有前后端完整闭环的，涉及三五个页面的产品功能。先做好，保留初稿、反馈和修改结果，提炼一两条下次还能用的判断，再在相似任务里试一次。

遇到什么情况时，需要人工介入，或者暂时不适用？

需求没想清楚、业务规则需要决定、AI 反复理解偏了，或者设计怎么改都不对时，人要继续判断和纠正。11 个节点是逐步磨出来的，不用为了形式，把所有小改动都强行走成大项目。

过程真的很苦，但是有了成果之后，你就可以吹牛去了，特别爽。更重要的，在这个过程中，你又会有很多的新思路，你会突然发现，自己 AI 段位升级了，变得通用了，能解决很多不同领域的问题了。

09 AI 雷达：一个人用 AI 做出的多因子量化择选系统，共振信号更有效

产品地址：https://3dauxcfyftly2.kimi.site

一个人干完一个团队的活

我是一名独立产品开发者，日常的工作是做量化策略研究，再把研究成果变成能用的产品。过去全靠查资料、手写回测脚本、手写前后端代码，最大的问题是一个人要同时当研究员、数据工程师和全栈开发，一个策略从想法到上线要以月计。2025 年起，我开始尝试用 AI 编程助手 Kimi 来辅助完成策略研究、回测工程、前后端开发与交互设计。经过数十轮迭代、每天数小时的使用，目前 AI 雷达已经上线运行：多因子共振信号、AI 择时、多空双榜、风控闸门、回测体系全部跑通。仍需人工完成的只剩两件事：策略方向的取舍决策，以及每一条数据结论的最终把关。

慢在体力活：半天排一个错

这项任务由我每天一个人完成：盯盘、验证新策略想法、迭代页面。

原来的工作流程是冒出想法后先翻书翻论文，再写 Python 回测，肉眼核对结果，然后依次写前端、写后端并部署。其中最麻烦的是回测——口径只要错一处，无论是字段映射、未收盘 K 线还是复权问题，结论就全部作废，人工排查一次至少要花半天；其次是前后端联调，既耗时又枯燥。但这些体力活不解决，想法验证的速度就赶不上市场变化，人被拖在琐碎环节里，腾不出时间做真正值钱的判断。

以一个具体任务为例：诊断「共振策略回测数据好差，问题出在哪里」这道题，过去需要自己写脚本，把止损、止盈、时间平三类出场逐笔分解，至少耗时半天；而现在只需一句话交给 AI，十几分钟就能拿到分层证据，止损 89 笔合计 −385.9%，止盈 41 笔 +322.4%，盈亏平衡胜率 37.3% 对实际 34.6%，谁是主犯、谁是从犯，一目了然。

从半天到十几分钟：AI 怎么给证据

选取一次代表性任务：共振策略的回测诊断与决策

提速 20 倍，质量没有打折

这些对比的结果是我每天使用，且经过数十轮迭代得出的，过程中涉及 10+ 个策略回测任务、4 次页面级改版。现在每个策略验证任务能少花一到两天，其中主要节省的是回测脚本编写和前后端体力活，数据核对与方向判断仍由我完成。

AI 也闯祸：天文数字背后的字段事故

事故一：字段映射事故。AI 在回测沙盒里犯过一个最大的错误是把 Gate.io K 线的字段映射弄错了，成交额被当成了开盘价，止盈收益一度显示为 +31,751,294% 的天文数字。这个错误是我亲手揪出来的。当时我没有直接采信这个结果，而是先跑了一个异常值扫描，发现收益最大的那笔交易明显不对劲：某币种退出价 76 万、入场价却只有 0.36。顺着这条线索，我又调用原始接口逐字段比对，最终定位到问题出在字段错位上。这件事给我留下的教训是：AI 的输出，永远要先过一道合理性闸门，数值离谱必有妖。

坑二：数据挖掘陷阱。我曾提出一个想法：「按震荡市/趋势市分开回测」。没想到 AI 先把我拦了下来。它指出：事后按市况切分，等于拿着答案找题目；正确的做法是用事前规则（ADX<20 记震荡、>25 记趋势）给每笔交易打标签，否则就是自欺欺人。这一次是我提方案、AI 纠正方法，角色互换了，挺有意思。

为了稳定使用，我又给自己加了三条约束：一是所有量化结论必须先回测再呈现；二是同一结论至少在两个周期维度（日/周/月）交叉验证；三是样本少于 30 笔，不下定论。同时，仍有两个环节我坚持留给人工：策略参数的拍板，比如共振阈值 3 要不要改成 4，以及涉及真实资金的任何开关。AI 只给证据，决策永远在我。

想上手，从一个小问题开始

这个方法适合有专业判断力、但缺工程人手的人，前提是任务结果可验证、可核对。开始前只需准备两样东西：一个具体的小问题，加上它的客观事实数据。第一次尝试，建议先拿「帮我诊断这个回测为什么差」这样的小任务练手。而一旦涉及真金白银、合规或对外承诺，就必须由人工介入判断。

上手时也别贪大，别从「让 AI 帮我做个 App」开始，而要从「让 AI 帮我回答一个我有标准答案的问题」开始。你先知道对错，才敢放权。

说到底，AI 不是替我们做研究，而是把研究里的体力部分收走，把判断的部分还给人。它回测，我拍板；它写码，我验收。分工清楚之后，一个人也能活成一支队伍。

10 一个人 + 一个 AI Agent，从零开发并运营一款恋爱教练 App

产品地址：https://kgjmgqtcgph5e.kimi.site/

没写一行代码，一款 App 已经上线运营

我是做产品的独立创业者，日常的工作是把产品想法快速变成能跑、能收到真实用户的产品。过去只有两条路：自己学编程，或者找外包，最大的问题是周期按周算、沟通成本比开发成本还高，改一版要等一周。几周前开始，我尝试用 AI 编程 Agent Kimi K3 来完成产品的全部开发、测试和部署。经过几十轮迭代，几乎每个工作日都有功能上线，目前「撩妹机器人·军师」已经稳定在线运营：AI 军师对话、兴趣指数测评、语音建档、裂变增长、数据后台全部跑通，也拿到了第一批真实用户和行为数据。仍需人工完成的只剩三件事：产品方向的判断、内容的专业性校准，以及真实用户视角的体验验收。

过去卡在哪：改一个按钮，等一周

我要做的是一款恋爱教练产品「撩妹机器人·军师」：男生把和女生的聊天记录贴进来，AI 军师判断关系到了哪个阶段，给出下一步可以直接复制的话术。

这件事只有我一个人，需求每天都在变。原来的路有两条：自己学全栈开发，周期按月算；找外包的话一个小工具报价几万，还得先写需求文档。最麻烦的其实不是写代码，而是迭代速度：产品早期靠快速试错活着，外包模式下改一个按钮的位置都要走一遍沟通、排期、验收，想法到验证的周期被拉到一周以上。热情等不起，数据也等不起；这些问题不解决，想法就永远停在 PPT 里。

从一句话到上线：AI 怎么把活干完

选一次有代表性的任务：给「建档」功能加语音辅助输入。用户口述一段对女生的介绍，AI 自动识别并填好表单。整个过程按发生顺序拆开讲，一共四步。

第 1 步：提需求。

**第 2 步：代码实现及测试。**它写完后端接口（从口语描述里严格提取 JSON：代号、年龄、职业、爱好、认识途径、当前阶段、备注）和前端录音组件，然后自己用无头浏览器模拟真机跑端到端测试：登录测试账号 → 打开建档 → 输入一段口语「她叫小琳，26 岁，是个幼儿园老师，朋友婚礼上认识的，我们已经单独约过三次饭了」→ 断言表单每个字段被正确填充（连「当前阶段」都被推断成「舒适感」）→ 断言数据库落库。测试全绿，自动部署上线。

**第 3 步：真实环境翻车。**我拿真机一用，语音识别根本转不动。我把问题原样丢回去：「这个语音识别没办法用，检查 bug，修复一下。」它的排查路径是：先探测服务端有没有转写接口（没有），再实测确认浏览器语音识别接口在国内网络环境和微信内置浏览器里大面积不可用，这正好解释了我的翻车。于是 AI 给到了他的修复计划：按钮永远显示、按错误码分级提示（没授权 / 网络不通 / 没麦克风设备）、6 秒无响应自动止损、兜底引导「点输入框，用手机键盘自带的语音输入」。修完再次自测、上线。

不凭感觉，凭版本记录说话

判断依据不是「感觉快」，而是版本记录：每一轮迭代都有可回滚的版本快照和自动化测试记录，哪一步是 AI 做的、哪一步是我改的，有据可查。

AI 也会一本正经地犯错：三个真坑

1. **坑一：AI 会一本正经地用错 API。**语音识别第一版它选了浏览器原生接口，技术上能跑，国情上跑不通（国内网络、微信浏览器都不支持）。发现方式是我人肉验收翻车。从此立下规矩：任何依赖外部环境的功能，上线前必须我亲手在真机上过一遍。
2. **坑二：AI 不懂业务语义。**产品里的阶段定义（恋爱方法论 SOP）它写得似是而非：把「肢体升级」错排到私密空间阶段，把「确立关系」错当成私密阶段的终点。发现方式是我对照迷男方法（M3 模型）原文逐条核对。我指出错位后，它重写了全部阶段定义，并同步改掉 AI 军师的系统提示词和语音建档的推断规则。这类「内容对不对」的问题，AI 自己永远发现不了。
3. **坑三：偶发延迟。**大模型提取字段偶尔超过 30 秒。处理办法是加「识别中」状态和超时兜底，不追求完美。

想照着做，从一个小需求开始

这个方法适合有产品判断力、但不想自己写代码的人，前提是需求能用一句话说清、验收标准明确。开始前只需准备两样东西：一个真实的小需求，加上一个能跑的环境（不用懂原理，会用就行）。第一次尝试，建议先拿「给自己的小工具加一个功能」这样的小任务练手，比如让一个表单支持语音输入。而一旦涉及钱、内容专业性或真实用户体验，就必须由人工介入判断，或者暂时不适用。

说到底，AI 不是替你做产品，而是替你雇了一支不要工资的工程队。但队长还是你：方向错了，工程队只会更快地把错的东西做出来。

11 坐席背不下的校区名单，我用 AI 做成了地图

我做成了什么

案例名称：校区定位地图工具。

一句话成果：当天下午做出可交互 Demo，两周内上线定位、产品弹窗和周边学校数据三层功能，覆盖 110 多家校区。

教育行业的陌拜通话里，坐席确认家长位置，常用的办法是把本区校区名字挨个念一遍，请家长自己对号。但家长通常只认家附近的路口、地标和小区，听完一串校名仍不知道哪家近，坐席只好再追问一轮。我用 AI 做了一个地图工具：家长报出熟悉的地点，坐席在地图上搜索，就能找到附近校区，再查看校区对应的课程信息。项目从位置查询逐步扩展到产品弹窗、周边学校与内部业务数据联动，两周内完成三层功能上线。

原来的办法为什么不够用

过去主要靠人记。坐席上岗前要背校区名称和地址，通话中再靠记忆检索；新人背不全，也得边接电话边补。周边学校、生源结构等信息，则要人工查资料、跨系统导出数据，再手工比对，往往只能支撑一次调研。

最麻烦的地方，是家长和坐席用的不是同一种定位方式。家长说的是“我家在某个路口旁边”，坐席脑子里存的却是校区名单。即使坐席把名单背熟，也未必能迅速完成这次对应。地址之外，各校区的开班品类、适配年级和招生政策又不一样，找到校区后还要继续查产品，通话节奏很容易断掉。

从一次定位需求开始逐层迭代

我的分工方式是先说清业务目标和优先级，让 AI 推演实现路径，承担逻辑梳理、数据整合、页面搭建、功能开发和调试。我不先把每个技术步骤拆完，再让它逐条照做；但方向是否符合通话现场、这一轮是否值得继续，仍由我判断。

第一步，先让家长说得出的地点成为搜索入口。

我提出的第一层需求很具体：把校区点位放到地图上，支持用道路、地标和小区搜索，并判断附近是哪家校区。输入是校区位置和家长熟悉的地点，期望输出是一个能点击、能搜索的地图，而不只是一份校区清单。

实现过程中，定位逻辑从“列出行政区域内的校区”调整为“以路口、主干道等日常认路方式为锚点匹配校区”。这个变化比页面上多几个按钮更关键，因为它直接对应家长表达位置的习惯。当天下午，AI 就做出了可点击的 Demo。我先验证这层查询能否满足定位需求，再决定下一步。

第二步，找到校区之后，把产品信息放到同一个入口。

第一层做完后，新的问题露出来了：地理位置能查，坐席仍然记不住各校区的产品差异。于是我继续提出需求，让 AI 把开班品类、适配年级、课程卖点和招生政策整理到校区点位弹窗里。坐席点开一个校区，就能接着查看产品，不必在地图和其他资料之间来回切换。

第三步，接入周边学校和内部业务数据。

定位和产品查询跑通后，再把上海各学段学校录入地图，联动呈现校区周边学校、梯队档次、在读生源分布、年级结构和校园出入口人流等信息。这里的迭代依据是前一层暴露出的业务缺口：先解决“附近是哪家”，再解决“这家有什么”，最后补上“周边是什么情况”。

上线后有什么变化

上线进度是目前最明确的结果：一个下午做出可交互 Demo，一周多上线可用版本，两周内完成三层功能。原先判断走传统研发可能要排期几个月，这属于对原流程的预估，不能当作同一项目的实测工时对照。

数据覆盖方面，110 多家校区点位已上图并带有产品弹窗；学校 POI 中，小学 1084 所、初中 832 所；累计 4942 条 POI 完成重编码与坐标纠正。这几组数字分别描述校区、分学段学校和累计处理记录，不能简单相加，也不直接代表使用效果。

一线的变化是，坐席可以围绕家长报出的小区或路口完成定位，产品差异也能随点位查阅，新人不必完全依靠背名单起步。新人上手变快是使用观察，目前没有培训时长、单通电话耗时或转化率的前后统计，因此不把它换算成效率或收入增幅。

地图项目还引出了话术分析和学科直播知识库等需求。不过，家长在不同阶段关注什么，来自同期的 TMK/CC 话术分析项目，不能全部算成地图工具本身的成果。

过程中哪些做法需要修正

第一层功能可用，不等于业务问题已经解决。最初解决的是“校区在哪里”，实际通话还需要回答“这家校区能提供什么”。产品弹窗正是第一轮验证后补出来的。如果只按最初的功能清单验收，很容易把“地图能打开”误当成“坐席已经够用”。

另一个教训是，不必一开始就把三层功能规划得很细，但也不能把“需求模糊”当成方法。有效的开放空间，是目标清楚、实现路径可以讨论；目标本身不清楚，只会让 AI 更快地反复做无用功。

低成本迭代也需要验收标准。坐席能否按家长的表达找到位置，弹窗信息是否对应当前校区，坐标纠正后点位是否可信，都是比“页面看起来完整”更重要的检查。数据更新和业务优先级仍要由人把关，不能因为 AI 改得快就省掉判断。

如果你也想做类似的事情，可以从哪里开始？

可以先选少量校区，只做“输入路口或小区，找到附近校区”的最小版本。准备校区名称、地址、坐标和少量真实但脱敏的位置表达，再请 AI 做一个可交互原型。第一轮先检查定位是否符合业务预期，不急着接入全部学校、生源数据和销售话术。

验证时，把输入和预期结果放在一起：同一个地点应匹配哪些校区，遇到同名地点该怎样确认，坐席下一步还需要看到什么。先把这些问题列为验收清单。原型能解决位置问题后，再把产品差异放进点位弹窗，最后考虑周边数据联动。

这个案例给我的收获，是让 AI 参与实现路径和产品逻辑的推演，同时把每轮结果放回真实通话场景里判断。人不必预先拆完所有步骤，但必须知道这一轮要解决什么，以及怎样才算解决。

12 AI写的代码谁敢合并？一个人的桌面AI伙伴与三道验证关

案例名称

桌面 AI 伙伴“栖伴”（QIBAN）开发实践：验证门禁 + 多智能体对抗审查 + 真机验收三道验证关，让 AI 生成代码敢合入主线。

案例简介

我是产品 + SRE 背景的独立开发者，业余时间开发桌面 AI 伙伴产品“栖伴”（QIBAN）：Windows 桌宠，React + TypeScript + Tauri 2 + Rust，功能含语音对话（录音 → 识别 → 流式分句 → 逐句合成 → 口型→ 打断）、本地记忆、手机配对。

团队就是我自己 + AI 编程智能体（Claude Code），一个人做通常需要小团队的事：Rust 后端、前端、测试、真机验收、发布。当前规模 8280 行 Rust、3390 行前端、2073 行测试、1565 行 IPC 契约，128 个提交。核心实践是把 AI 从写代码的工具升级为开发流程本身，用“验证门禁（每个 commit）+ 多智能体对抗审查（每个 PR）+ 真机验收（合并后）”三道验证关层层把关：以最近语音功能批为例，10-07 一天合入 7 个语音 PR，10-09 脚本化真机验收 8 用例全绿，全程一人 review。

之前的老方案是什么，存在什么问题

写代码早已不是瓶颈，验证才是：AI 生成代码的速度远超个人逐行审查的能力，但没有验证纪律的 AI 代码不敢合入主线。具体有三个问题。

1. mock 测试会撒谎：浏览器测试里的 mock 对象与真机环境行为不一致（本项目有具体案例：真机 WebView2 的注入对象不可写，mock 是普通可写对象——这类差异 mock 自己永远测不出），“测试全绿”不等于“真机能跑”；
2. 个人开发没有第二双眼睛：传统代码评审在这套流程里不存在，需要一个替代品；
3. AI 审查 AI 可能共模：两个模型互相点头不构成证据——审查结论本身也要被验证。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

三道验证关层层递进：

1. 验证门禁（每个 commit）：全套脚本化、AI 自己跑自己修到绿——Rust 侧 cargo fmt / clippy -D warnings / cargo test（197 个测试），前端 npm run check（类型+单元）+ Playwright 全套（55 个浏览器用例，约 15 秒），外加文档结构校验 verify:docs。门禁不绿不进下一步。
2. 多智能体对抗审查（每个 PR）：合并前用 workflow 编排多个审查智能体分维度找问题（生命周期时序 / 行为矩阵完整性 / 测试真实性），每个发现再派独立的「反驳者」智能体验证——反驳不掉才算真问题。防御性代码必须过 mutation 验证：临时删掉它 → 测试必须变红，才算被真正钉住。最近一次审查（PR #51）：7 个智能体、4 个发现、全部确认成立。
3. 真机验收（合并后）：CDP 远程调试连打包后的 Windows exe + 本机 HTTP fixture（零真实凭据）+ 合成音频流替代真实麦克风 + 全新一次性 profile。验收脚本断言：raw WAV 走 IPC 字节级一致、无 Authorization 头、设备轨道全部释放、无 blob 泄漏、打断发生在传输层（fixture 服务端观测到连接 abort）。8 用例可重复执行。

安全设计同步内建：密钥只由 Rust 从 Windows 凭据管理器读取、永不跨 IPC、公开仓库零密钥。

过程中踩过的坑：

1. AI 辅助开发的瓶颈从「生成」移到了「验证」：门禁 + 对抗审查 + 真机验收，是让 AI 产出敢合入主线的三件套——缺一个都会退化成「看起来很快、其实不敢用」；
2. AI 审查 AI 是有效的，但必须结构化：维度分工、独立反驳、mutation 验证三层缺一不可；不然就是两个模型互相点头；
3. mock 全绿不等于真机能跑：观察与断言要尽量打到真实边界（传输层连接 abort 比页面侧“已取消”字符串是强得多的证据）。

与旧办法相比，新办法的结果如何（数据对比）

（以最近的语音功能批为例，全部数字可溯源到主线 git）

• 交付速度：10-07 一天合入 7 个语音 PR（含桌宠语音全链 T11 与口型 T12，晚间三个 PR 间隔仅 16 分钟）；10-09 脚本化真机验收 8 用例全绿；同日用户人工听感反馈（“切焦点停止朗读”）当天定位、过对抗审查、修复合入——从编码到验收全绿两天，反馈修复当天。
• 质量证据：每 PR 有对抗审查记录（最近一次 7 agents / 4 findings 全确认）；回归有 mutation 验证（baseline 0 红 → 摘防御各精确 1 红）；真机有可重复验收脚本（result.json + 32 条 IPC 命令流 wire 留痕 + 服务端连接 abort 观测）。
• 全程一人 review：AI 承担编码与大部分排查，人承担问题定义（“解决什么”）、产品语义拍板（如“失焦该不该停止朗读”）与最终判断。

通过这个 AI 落地案例，我的收获有哪些

1. 验证纪律是 AI 产出的合入许可证：没有三道验证关，AI 写代码再快也不敢合并；有了它们，单人团队也能保持接近生产级的质量。
2. 对抗审查必须结构化：维度分工 + 独立反驳 + mutation 验证三层，才能避免“两个模型互相点头”的共模失败。
3. 人的价值上移了：写代码的时间占比大幅下降，但问题定义、产品语义取舍、诚实声明能力边界（哪些验证过、哪些没有）反而更关键——AI 不会替你拍板，也不该替你拍板。
4. 坑就是案例：mock 与真机的差异、sed 的贪婪匹配、effect 竞态——失败比成功更有参考价值，也都沉淀成了交付记录和自动化测试。

13 如何用 AI 辅助知识库改版

本文根据 2026 年 10 月 10 日的工作聊天、代码提交及当时的验证记录整理。案例聚焦知识库聚合入口页改版，成果口径为本地开发与验证完成；后续发布情况不在本次记录范围内。

先说清楚，我做成了什么

我是 Ruonan，一名前端工程师。日常做页面开发时，我经常把需求、截图和现有代码交给 Codex，让它结合项目分析，再根据我的反馈实施。2026 年 10 月 10 日，我拿到一份新版知识库页面源码，需要把它融入已有网站。难点在于：新版与原项目采用不同技术框架，而且页面背后已有登录、路径、分享等业务规则。我让 AI 先找出冲突，再由我决定以哪版为准。最终，目录从 13 项、3 类调整为 18 项、4 组，保留了原有业务能力，并留下本地提交和验证记录。

原来要做什么，为什么这件事值得改变

这次改的是用户浏览知识库的聚合入口。新版重新组织目录、更新文案和卡片交互；现有页面则已经接入账户菜单、分类筛选、PC 搜索、页脚链接及分享逻辑。表面上是换布局，实际需要逐项判断：哪些变化属于本次需求，哪些旧功能必须继续可用。

例如，新版源码中的登录入口只是一个固定链接，原页面却能显示登录后的头像和账户菜单；新版 PC 页脚是一张图片，旧页脚的协议、合作、备案信息可以点击。如果直接照搬，页面可能看起来更接近新版，却丢失用户原来能完成的操作。参考源码使用 React / Vinext，现有项目使用 Nuxt / Vue，组件和路由也无法直接替换。

手工处理通常要来回查看两套源码，整理差异、确认取舍，再分别修改桌面端和手机端。最费心的是这些差异分散在目录数据、组件和公共配置中，漏掉一处就可能影响已有行为。我希望 AI 先完成这层比对，让我的精力集中在业务判断上。

我具体怎样把 AI 用进去

**第一步，把新版源码、现有项目和决策方式一起交给 AI。**我指定了本地开发分支、需要修改的知识库页面，并补充源码压缩包。最关键的是先要求分析冲突。下面是当时指令中的原话：

这版源码会与现有的项目有冲突，你需要分析出哪些地方冲突，我来告诉你以谁为准

这个约定让第一轮产出成为一份可讨论的差异清单。AI 把目录分类、文案统计、卡片布局、卡片点击、搜索重置、登录入口、PC 页脚、分享文案、链接路径整理成 9 类，并说明采用新版可能改变什么。我的判断因此有了具体对象。

**第二步，把差异翻译成用户会遇到的变化。**目录和分组采用新版，能展示新的组织方式；卡片改成整卡点击、在新窗口打开，符合新版交互；账户菜单和可点击页脚保留现有实现。原 PC 页面还支持点击标题重置搜索，新版静态标题没有这项行为，因此需要把重置能力补回来。

链接也是需要单独判断的一项。参考源码把部分域名和路径写死，而原项目要兼顾本地环境、不同站点域名和 /space 路径前缀。最终做法是保留原项目的路径规则，让新目录中的卡片继续正确指向已有阅读页。AI 同时核对了 18 个目标阅读页的路由已经存在，避免把入口改版扩大为内容页重建。

**第三步，由我确认取舍，再进入实现。**我认可了大部分建议，并明确了分享文案和路径的选择。当时的回复很短，但已经足以形成清晰的实施边界：

分享文案使用新版，链接与路径采用现有，其他的按建议

随后，AI 将新版目录、布局和交互适配到 Nuxt/Vue 项目中。桌面端和手机端共用目录数据，减少两端内容不一致；手机端描述保留两行截断，移除旧预告卡；PC 端增加明确的“重置筛选”按钮。分享标题与描述使用新版，原有分享封装和埋点继续沿用。

**实现中还有一项不容易从截图看出的处理：新增样式限定在知识库页面范围内，避免把参考源码的全局样式带入整个站点。**账户菜单、页脚、路由也沿用现有项目机制。这些细节让改版能够与原系统协同工作，也是我关心的交付质量。

**第四步，用确认过的规则检查交付。**除了看新页面是否接近参考，还要检查目录数量、分类、卡片去向、PC 搜索重置、账户区域和页脚是否符合取舍。AI 继续完成项目检查、开发环境冒烟检查和多宽度浏览器模拟，并在最终说明中列出验证结果与未验证项。

有没有效果，我怎样判断

可以直接核对的结果是：入口目录从 13 项、3 类变为 18 项、4 组，整卡访问等新版交互已经落入原项目，同时保留了现有账户、路径和页脚能力。本次调整的是入口展示与组织方式，18 个阅读页原本就已存在。当时保存的验证记录包括：

• 项目检查通过：包含代码规范、类型检查，以及 8 个测试文件中的 62 项测试。这是当次项目测试总数。
• 4 种开发环境冒烟模式通过，使用隔离的模拟上游数据，覆盖不同开发访问方式。
• 320–1440px 的 9 档浏览器模拟验证通过，同样基于隔离数据环境。

对我而言，这次使用 AI 的价值体现在把分散的比对、跨框架适配和检查工作串起来。原本需要逐处阅读和记录的差异，变成了可以逐项确认的清单；确认后，实施与验证又能围绕同一组规则展开。现有记录没有人工工时基线，也没有访问量或转化率对比，因此这里不估算效率百分比。

这轮工作最后形成了本地提交。历史记录结束时尚未推送、尚未发布，真机和 App 也未验证。浏览器模拟通过说明已检查相应宽度和规则，真实登录跳转、分享渠道与发布后的业务行为，仍需在对应环境继续验收。

不好用的地方，以及我怎样补上检查

第一个提醒是，要先识别参考源码中省略了哪些业务能力。固定登录链接、图片页脚在独立页面里可以成立，放进已有系统就需要重新判断。如果只要求“按照源码改页面”，AI 缺少取舍依据，很容易把原功能一起替换。把冲突清单放在动手之前，可以更早发现这些问题。

第二个提醒是，约定要细到能验收。“采用新版文案”在这次明确指分享标题和描述，页面 SEO 标题仍沿用原版；“保留搜索”对应 PC 端，手机端继续使用分类筛选。把这些范围写明，才能避免自己和接手同事对“完成”产生不同理解。

第三个提醒是，检查结果必须带环境。隔离数据能帮助快速检查页面和路径规则，浏览器可以模拟多种宽度，但真实设备、App 和线上服务仍有各自的运行条件。我的做法是把已经验证、尚待验证的事项一起放进交付说明，便于下一步继续。

如果你也想做类似的事情，可以从哪里开始？

这种协作方式适合把新版设计或参考源码融入已有网站的前端任务。开始前，准备好参考源码、原项目、目标页面，以及必须保留的业务能力。可以先从一个页面开始，让 AI 输出“现状—新版变化—影响—建议—待确认项”。下面是根据这次经验整理的提示词：

请对比【参考源码】与【现有项目的目标页面】，先列出框架、目录数据、交互、登录、链接路径、分享和样式范围的差异。逐项说明直接采用新版会影响什么，给出建议，并标出需要我决定的事项。确认后再实施；交付时按确认清单验证，写明测试环境、结果和未验证项。

人工最值得投入的环节，是判断用户原来能做什么、本次希望改变什么，以及哪些变化超出了需求。AI 可以阅读代码并提出建议，最终采用哪种业务行为，仍需要熟悉产品的人决定。方案确认后，把它保留下来，既是实施依据，也能直接成为验收清单。

这次让我更愿意把 AI 用在改版前的分析阶段。先看见冲突，再明确选择，后面的代码修改和验证就有了共同依据。这样一次改版留下的，除了页面，还有一份同事能理解、后续能继续检查的决策记录。

整理依据与发布说明

主要依据：《分析知识库页面源码冲突》（2026 年 10 月 10 日）、同日提交 86868e5 及当时的项目检查、开发冒烟和浏览器模拟记录。目录数量与关键行为已对照该提交及其父提交核查。

署名信息：Ruonan，前端工程师；头像为 AI 生成的虚拟人物。

14 代码能跑了，我还会让 AI 再「挑一次错」

我做了什么

我是一名开发工程师，平时会用 Codex、Copilot 辅助写代码。刚开始，我主要把它们当成代码补全工具，写到一半时补几行重复代码，或者根据注释生成一个方法。后来我发现，开发中真正让我反复返工的，往往不是主流程不会写，而是一些当时没想到的情况。

比如输入为空时怎么处理，几个条件同时满足时应该走哪个分支，下游报错后接口应该返回什么，以及改动旧逻辑后会不会影响原有功能。这些问题以前主要靠我自己检查，再通过调试和测试一点点补齐。需求一复杂，注意力很容易放在“功能先跑通”上，边界情况就可能考虑不全。

现在，主流程写完以后，我会把需求、相关代码和自己的实现一起交给 AI，请它专门找遗漏。业务规则仍然由我判断，AI 给出的建议也不会直接照搬，但它可以从另一个角度再检查一遍。实际使用下来，我对逻辑完整性的考虑比以前更充分了，也能更早看到一些需要补充或找产品确认的问题。

以前的做法，问题出在哪里

过去接到一个开发任务，我通常要先理解需求，再拆成几个步骤，然后开始写代码。主流程完成后，我会自己顺着代码检查一遍，接着进入调试、联调和测试。

这套做法本身没有问题，但比较依赖个人当时的经验和状态。同一段代码刚写完时，思路还停留在自己的实现路径上，自查时也很容易沿着这条路径再走一遍。正常流程一般能覆盖到，但不常见的输入、条件组合和异常路径不一定能马上想到。

如果遗漏在编码阶段发现，通常补一个判断、加一个测试就能解决。等到联调或测试阶段才发现，就需要重新切回上下文，定位原因、修改代码，再做一轮回归。有时改动不大，但前后沟通和重新确认会花掉不少精力。

我没有专门统计过这部分到底占多少时间，所以不能说用了 AI 以后效率提高了百分之多少。我的直接感受是，问题发现得越晚，处理成本越高。既然 AI 已经参与了写代码，我就想试试：能不能让它也参与写完后的那次检查。

我具体怎么用

我现在的使用过程并不复杂，大致分为下面几步。

1. 先把背景说清楚

我不会只截一小段代码，然后问“这段有没有问题”。如果 AI 不知道需求目标和上下文，它只能按通用经验猜，答案看起来合理，却可能和实际业务不一致。

我一般会提供这些内容：这次要实现什么、相关代码在哪里、已经确定的业务规则、哪些旧行为不能改变，以及目前还有哪些地方不确定。如果代码较多，就先让它阅读和复述，不急着生成修改。

我常用的开场类似这样：

下面是一个已有接口的相关代码。这次需要增加一项判断，但不能影响原来的正常流程。请先说说你对现有逻辑和改动目标的理解，并列出还需要确认的信息，先不要改代码。

这一步可以先看出它有没有理解偏。如果理解错了，后面的代码写得再完整也没有意义。

2. 用 AI 辅助完成第一版实现

确认方向以后，我会让 AI 给出实现建议，或者继续由 Copilot 做局部补全。我会重点看它有没有复用项目里已有的方法，是否改变了原来的执行顺序，以及是不是为了一个简单需求增加了过多抽象。

第一版代码能运行，并不代表可以结束。这个阶段 AI 更关注“怎样把需求实现出来”，和开发者一样，也容易沿着正常流程往下写。所以我会再单独问一次，而且明确告诉它：这次不要继续写代码，只检查遗漏。

3. 单独让它找边界和异常

我会把当前实现一起发给 AI，然后这样问：

先不要重写代码，请检查当前实现可能漏掉的情况：

- 正常分支有没有覆盖不全或顺序冲突；

- 空输入、极端值和多个条件同时出现时会怎样；

- 调用失败后，返回和异常处理是否合理；

- 这次修改会不会影响原有分支。

请说明每个问题在什么情况下发生。不能从现有需求判断的，请标记为“需要确认业务规则”，不要自行补规则。

最后一句很重要。最初使用时，我没有加这个限制，AI 经常会替我假设业务应该怎么处理。它的解释很顺，但实际规则可能根本不是这样。现在我会要求它把“代码能够判断的问题”和“需要找人确认的问题”分开。

4. 不直接采纳，逐条判断

AI 给出的建议，我一般会逐条看。

有些问题可以直接从代码验证，比如空值是否会报错、某个分支是否永远进不去。这类问题可以补测试或实际运行确认。有些涉及状态优先级、兼容旧数据等业务规则，就需要回到需求，必要时找产品或相关同事确认。还有一些只是理论上可能发生，系统其他地方已经做了限制，继续加判断反而会让代码变复杂，这类建议我不会采纳。

修改完成以后，正常的调试和测试仍然要做。AI 的作用是多提供一个检查角度，不是替代验证。

一个脱敏后的任务过程

我平时遇到过一类比较典型的任务：在一个已有接口里增加新的条件判断，同时保持原有流程不变。我先按需求完成修改，正常输入下结果也符合预期。如果按以前的习惯，这时就会开始联调。

这次我把需求说明、原来的代码和修改后的版本一起交给 AI，让它只检查逻辑。它提出了几个方向：输入字段缺失时，新判断是否会提前报错；两个条件同时成立时，当前分支顺序是否符合业务；下游调用失败后，现有处理会不会让调用方误以为成功。

其中有些问题看代码就能确认，我补了相应测试；有一个涉及条件优先级，代码本身给不出答案，我重新核对了需求；也有一项建议不符合真实调用场景，我没有采用。

AI 并没有直接告诉我一个“正确答案”。它更像是在我准备进入下一阶段前，提醒我还有几个地方值得再看一眼。对我来说，这已经很有用了。

实际效果怎样

目前我没有做严格的耗时或缺陷数量统计，这套方法也还在持续使用和调整。因此，我更愿意把效果描述为工作过程的变化，而不是给出一个不准确的效率数字。

最明显的变化，是我的注意力从“怎么把代码写出来”挪出了一部分，放到了“规则是否准确、逻辑是否完整”上。AI 可以完成部分重复代码，也能帮我枚举一些可能情况，我就有更多精力判断这些情况在真实业务中是否成立。

第二个变化是，一些问题被发现得更早。AI 不可能覆盖所有边界，但它会提醒我检查空输入、条件组合、异常返回和旧逻辑影响。过去这些检查比较依赖我当时能不能想到，现在至少多了一次相对固定的提醒。

我下一步想做一个简单记录：哪些问题是在写代码时经 AI 提醒发现的，哪些仍然到了调试或测试阶段才出现。等积累一段时间后，再看它具体减少了多少返工。现阶段能够确认的是，它让我写完主流程以后，不会那么快地把“能跑”当成“做完”。

不好用的地方

AI 最大的问题是，它不知道真实业务，却很愿意给出一个完整答案。上下文不够时，它会自行假设规则；如果直接照搬，很可能技术上说得通，业务上却是错的。

另一个问题是过度防御。让 AI 找边界，它常常能列出很多极端情况。如果每一项都加判断，代码会越来越长，真正的业务逻辑反而不清楚。所以看到建议后，我会再问自己：这种输入真的可能出现吗？是不是已经在上游限制了？项目里的框架是否已经处理？

我也遇到过 AI 对错误逻辑解释得很流畅的情况。它能说明“为什么这样写”，不代表程序运行结果一定正确。因此，只要涉及关键条件和异常处理，我仍然会看调用链、构造输入并跑测试。

如果业务规则本身还没有确定，或者涉及资金、权限等风险较高的逻辑，我会以人工分析和确认结果为主。AI 适合帮助找问题，不适合代替人确定规则。

如果想试，可以先从一段小代码开始

这个方法更适合已经能够独立判断代码、平时需要维护多分支逻辑的开发者。第一次不用把整个需求都交给 AI，可以选一个已经完成主流程的小接口，把需求和相关代码提供给它，然后只问三个问题：

1. 这段逻辑还可能漏掉哪些边界条件？
2. 哪些情况下，结果可能不符合预期？
3. 哪些问题不能从代码判断，需要先确认业务规则？

拿到回答后，不要马上让 AI 自动修改，而是先判断哪些值得处理，再通过调试和测试验证。

我现在仍然会用 AI 补全和生成代码，但这已经不是我觉得最有价值的部分。对我来说，更实用的变化是：代码写完后，多了一个可以随时调用、愿意反复帮我检查的“第二视角”。它不一定正确，也不能替我负责，但经常能提醒我再多想一步。

15 从笨重 IDE 到自研工具：AI 写的 Git 管理器，让 Claude Code ／ Codex 更顺手

案例名称

LightGitPad：用 AI 协作开发的轻量代码工程与 Git 记录管理桌面工具，把「工程文件、代码、Git 改动和历史」放进一个窗口，配合 Claude Code / Codex 等 AI 编程助手使用。

案例简介

我在使用 Claude Code、Codex 等 AI 编程助手开发软件时发现一个实际问题：开发越来越多地在聊天里完成，助手能改文件并解释结果，但我仍然需要亲眼确认工程结构、代码内容、哪些文件被改过、具体改了哪几行。为了核对一次改动就打开 IDE，负担比较重；轻量文本编辑器适合看单个文件，却缺少完整的工程和 Git 视图。我把这个日常痛点转化为一个具体产品需求，再用 AI 协作开发 LightGitPad（github.com/felixlwang/LightGitPad）：把工程文件、代码、Git 改动和历史放进一个轻量桌面窗口，让人更容易检查 AI 的工作结果。已形成支持 Windows 和 macOS 的可运行桌面工具，具备工程文件树、多标签代码阅读与编辑、左右对照 Git 差异、路径历史和 Markdown 预览等能力。

之前的老方案是什么，存在什么问题

针对查看工程和核对改动的需求，原有方式主要是打开 IDE，或在文件管理器、轻量文本编辑器和 Git 工具之间来回切换：先找文件，再读代码，再查差异和历史。这些工具各有用途，但只为了看一眼工程和改动，需要维护多个窗口和上下文；单文件编辑器也难以把工程结构、当前差异和提交记录连起来看。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

工具：Claude Code、Codex 这类能够直接读取和修改工程文件的 AI 编程助手。整体分工：我提出真实使用场景、确定范围并验收结果；AI 辅助分析方案、实现代码、排查问题和整理说明。步骤：

1. 先把目标说具体：重点解决工程浏览、代码阅读、Git 差异和历史查看，明确产品的轻量定位；
2. 把需求拆成可检查的功能：逐项迭代文件树、文本编辑器、差异视图、历史视图和 Markdown 预览等能力；
3. AI 修改后核对实际文件和 Git 差异，再通过构建、必要的测试和界面检查确认行为；有问题就带着具体证据反馈，再继续修正；
4. 把运行、安装和使用方法写成用户能看懂的说明，形成可交付的 Windows 和 macOS 桌面工具。

最关键的一步：把「助手说完成」转化成「人能检查的结果」——需求、实际改动和验收行为要对得上，发布等外部操作另行明确授权。LightGitPad 本身不调用 AI 服务，而是用 AI 协作开发出来、帮助人核对 AI 改动的配套工具。

过程中踩过的坑：

• 最需要警惕的是把 AI 的完成说明当成验收结果：代码能编译，不等于界面行为和用户需求都正确；要回到实际文件、差异和操作结果逐项核对。
• 把范围和权限写清楚：功能取舍、允许修改的路径、提交和发布的边界，都要让助手知道。尤其多人或多个会话一起工作时，要划清写入范围，避免相互覆盖；Git 提交也要核对具体文件和改动，不能把无关内容一起带进去。

与旧办法相比，新办法的结果如何（数据对比）

• 具体成果：形成 LightGitPad 这个可运行的桌面工具，支持 Windows 和 macOS，已具备工程文件树、多标签代码阅读与编辑、左右对照 Git 差异、路径历史和 Markdown 预览等能力。
• 工作方式变化：需求和反馈可以在对话中组织，AI 承担一部分实现与排查工作，人把精力放在范围判断和实际验收上；核对 AI 改动时，可以在一个窗口里查看工程、代码和 Git 记录，减少为看一眼结果而切换多种工具的步骤。
• 一个可核实的产品指标：项目说明记录了 Windows v0.2.15 打包版打开工程时，程序自身私有内存约 30 MB——这个数字说明轻量目标的实现情况，不代表 AI 带来的效率提升比例。

通过这个 AI 落地案例，我的收获有哪些

1. 从真实而具体的痛点开始：把「AI 改完要亲眼核对」这个日常痛点做成产品需求，工具一出生就有人用。
2. **有工具或功能需求，可直接交由 AI 开发实现：**过去若需要特定能力，往往要耗费大量精力寻找替代方案；如今借助 AI，不仅效率极高，产出成果也更贴合自身要求。
3. 产品取舍、证据判断和最终验收仍需要人负责：AI 可以加快实现，但范围、权限、提交边界这些判断不能全交给助手——尤其多会话协作时，写入范围不划清就会互相覆盖。

16 从 20 分钟到 2 分钟：我用 Codex 搭建小红书图文排版工具

我是极客时间的李嫚嫚，日常会围绕热点和文章观点制作小红书图文笔记。过去，内容整理好后，我还需要使用稿定设计或小红书自动排版工具调整格式，大约花 20 分钟。2026 年 8 月 20 日，我开始借助 Codex 搭建“即刻成文”，到 9 月初，已经可以提供给同事使用。现在，我自己的文章观点类笔记都在通过这个网站制作，排版生成、预览检查、修改和下载合计约需 2 分钟。这是个人日常使用中的估计，前期资料整理、观点写作和最终发布仍由我完成。

内容已经准备好了，排版还要再花一轮时间

我经常遇到的一项任务，是热点出现后整理相关内容、提炼观点，再制作成适合小红书发布的图文笔记。

这类任务需要尽快完成，但文字写好以后，还要把它变成一组可以阅读的图片。内容长了，需要分成多页；加入插图后，还要考虑文字与图片怎样安排，以及整组图片的尺寸和样式是否统一。

以前，我主要使用稿定设计和小红书自动排版工具。在自己的任务中，我遇到的情况是：稿定设计调整格式比较耗时，小红书自动排版则经常出现格式问题，需要继续修改。内容整理完成后，排版大约还要花 20 分钟。

当时，我经常看到同事们尝试用 AI 提效，也开始想：这项反复出现的工作，能不能做成一个可以重复使用的工具？

我的需求很具体：使用者放入已经准备好的文字和插图，网站自动分页、排版，再导出统一尺寸的图文卡片。这样，下次遇到同类任务，就可以直接沿用这套制作方式。

我具体怎样把 AI 用进去

第一步，把工作需求整理成网站要完成的流程

2026 年 8 月 20 日，我开始使用 Codex 搭建网站。

这次实践中，Codex 帮助我开发工具。“即刻成文”承担的工作，则是把已有文字和插图排版成图片。因此，我需要向 AI 说明的，是使用者从输入内容到拿到成品，要经过哪些步骤。

围绕这个目标，网站逐渐形成了一条基本流程：粘贴内容，查看自动分页结果，调整样式，再下载图片。

在这个过程中，我负责提出实际使用要求：长文字需要完整呈现，图片能够参与排版，多张卡片保持统一尺寸，下载前可以查看效果。Codex 辅助完成网站的实现，再根据后续反馈继续调整。

第二步，做出第一版，再放回实际工作中看问题

网站最初的生成过程比较顺利，但第一版只能勉强运行，距离真正好用还有差距。后续需要处理的问题，主要集中在功能和排版细节上。

这让我开始关注完整的制作结果。一段内容能显示出来，还需要看分页后是否适合阅读；功能可以操作，还需要看它能否帮助我顺畅完成一次图文制作。

到了 9 月初，网站已经达到可以提供给同事使用的程度。此后，我继续在自己的笔记制作中使用它，也继续发现需要优化的地方。

图注：输入文章后，网站自动分页，使用者可调整样式、查看预览并批量下载。

第三步，遇到插图换行问题，补充需求和参考图

后期优化中，令我印象最深的是插入图片后的换行问题。

文字和图片需要共同组成一张可阅读的卡片。插图后换行表现异常，就会直接影响使用。这时，仅仅继续增加功能，并不能解决眼前的排版问题。

我重新向 Codex 说明了自己的需求，又提供了几张优秀案例图，让它继续优化排版。经过后续调整，这个换行问题最终得到了解决。

这次优化中，我补充的材料是自己的使用需求和参考图，Codex 辅助完成网站修改。参考图把期望效果呈现出来，帮助我更清楚地表达对页面安排的要求，也给后续调整提供了可以对照的方向。

当时没有保留原始提示词，因此这里按回忆概述沟通过程。对我来说，这次经历中可以复用的方法，是把实际问题说清楚，并提供能帮助理解预期结果的材料。

下面几张是当时提供给 AI 的参考图，围绕 Agent Harness 的公开讨论整理：

第四步，让第一次使用的人也能完成制作

随着网站逐渐完善，我也开始考虑同事第一次打开它时的体验。

作为搭建者，我知道功能在哪里、应该怎样操作，但第一次使用的人需要说明。因此，我加入了可以自由拖动的“极客喵”小客服，用来介绍功能、解答常见操作问题。

这也是我对工具可用性的一个判断：使用者遇到疑问时，能够找到帮助，继续完成手里的任务。

有没有效果，我怎样判断

目前，“即刻成文”已经进入我自己的日常工作流程。文章观点类笔记，我都会通过这个网站制作。

一篇讨论 AI 与软件使用门槛的观点文章，可以作为实际输出的例子。整篇内容最终导出了 5 张 PNG 图片，每张尺寸均为 1728×2304 像素，比例为 3∶4。

从成品中可以看到，第一张包含极客时间的品牌信息和文章标题，后续卡片延续正文，重点观点通过加粗区分。一篇连续的文章，被整理成了一组可以按顺序阅读的图片。

图注：一篇观点文章实际导出的 5 张卡片，每张尺寸为 1728×2304 像素。

这些时间来自个人日常使用估计，具体耗时会受到内容长度和配图情况影响。2 分钟不包含前期资料整理和观点写作。

这组 5 张成品展示的是实际输出结果，耗时描述依据的是我的日常使用经历。目前，我还不了解同事的实际使用情况，因此，案例中的效果主要依据我自己的持续使用体验。

哪里不好用，哪些判断仍需要人工完成

插图换行的问题，是这次开发中一个有代表性的难点。第一版能够运行后，仍然需要处理这些会影响最终使用的细节。

通过这次优化，我更重视向 AI 提供具体材料。排版要求很容易停留在感受上，而参考图可以呈现期望效果。把问题和参考材料放在一起，更有助于推进调整。

同时，自动生成图片之后，人工检查仍然必要。文字是否准确、图片是否完整、分页是否影响阅读，以及预览与下载结果是否符合需要，都需要使用者判断。

目前，网站预览和最终下载结果已经基本保持一致，但具体内容仍可能需要继续调整。遇到插图安排不合适、文字层次不清楚或分页影响阅读的情况，也需要人工介入。

这次经历让我意识到，自己对运营工作的理解能够帮助 AI 开发：我知道图文最终用在哪里，也能判断哪些问题会影响使用，再把这些判断转化为下一轮调整要求。

如果你也想做类似的事情，可以从哪里开始？

如果你的工作中，也经常需要把文章观点整理成成套图片，可以先拿一篇内容已经确认、配图不多的短文，到“即刻成文”中完成一次制作。

先粘贴内容，查看分页，再调整样式、下载图片，最后逐页检查。第一次尝试，重点是走完完整流程，判断它是否适合自己的工作。

如果希望借助 AI 搭建自己的工具，可以先选择一项熟悉、反复出现的小任务，准备真实输入，明确希望得到的结果，再让 AI 帮助实现第一版。使用中遇到问题时，把问题、预期效果和参考材料一起补充给它，继续修改。

作为一名文科背景的运营人员，我此前没有想过自己能够独自搭建网站。Codex 帮助我把想法推进到了可以使用的阶段，也让我开始尝试把工作经验沉淀成能够复用的工具。

我还在探索实况照片、音频、可播放视频、多人编辑和多平台适配等方向。现阶段，最重要的是继续根据真实使用反馈，完善排版和图片处理。

想开始尝试的同事，可以先选一篇短文，完成第一次制作。一次具体任务，就能帮助自己判断工具是否适用，也能为下一次优化提供清楚的反馈。

体验入口：即刻成文

17 从一句主题到一支 MV：我用 AI 制作极客时间九周年主题音乐视频的实践

让“AI，落地见真章”从一句口号，变成看得见的故事

极客时间 9 周年，我们想传递一个主题：AI，落地见真章。

这句话不只是口号。我想让大家真正理解：只有当 AI 走进日常工作、解决具体问题，它才对业务产生价值。

围绕这个主题，我们想过微电影、广告片等不少形式，但总觉得还差一点意思。我想找一种更有趣、也更容易让人产生共鸣的表达方式——最后选择了说唱＋MV：把工作中使用 AI 的困惑写进歌词，再用带幽默感的画面把它演出来。

先找到真实的痛点，再把它写成歌词

第一步是写歌词。这比我预想的难。

我自己写了很多遍，始终没达到想要的效果。打工人用 AI 的故事并不缺笑点，但如果只写几个段子，热闹过后什么也留不下。我更想弄清楚：大家真正卡在哪里？哪些经历会让人听到后脱口而出——“这不就是我吗？”

为此，我访谈了十几位朋友，同时用 ChatGPT 整理小红书上相关帖子和评论里反复出现的问题，再结合访谈内容寻找共同的困惑。

有一个现象让我特别有感触：工具用了不少，课也学了一堆，但回到具体工作里，还是在不同窗口之间搬运内容、复制粘贴。于是，歌词里有了这样一段：

别人用 AI，产品都上线，
我用 AI，还在两头传文件。
工具咱也有，本事咱也在，
怎么一忙起来，还是复制粘贴？

这几句想写出一种熟悉的落差：大家愿意学，也愿意试，但从“用过 AI”到“用 AI 把事情做成”，中间还有一段路要走。

经过几轮调整，歌词逐渐有了贯穿全曲的线索：从使用 AI 时的忙乱和困惑，走向真正解决问题，再落到大家一起学习、一起实践。

歌词和旋律最终在 Suno 里生成。这个过程中，ChatGPT 帮我整理材料、辅助修改表达；但哪些问题值得写、哪些句子有共鸣，仍然需要我根据访谈和自己的判断来选择。

用幽默讲困惑，让观众愿意看下去

确定歌词后，我希望整支 MV 的气质是幽默、轻松的。主题涉及工作中的真实问题，但表达不必沉重。

比如“还是复制粘贴”这一段，说的是很多人都遇到过的困境。我想让一群同事一起接唱，让不同角色共同说出这份无奈。

但如果大家只是站成一排唱歌，画面又会显得单调。所以设计镜头时，我会继续追问：他们唱这句时正在做什么？能不能让“两头传文件”的忙乱直接发生在画面里？人物的动作能不能既带出笑点，也帮助观众理解歌词？

我开始把歌词当作设计画面的依据：每一段都要找到一个具体场景，让观众看到其中的处境。

把脑海中的画面，拆成 AI 可以协助完成的镜头

有些歌词对应的画面，我一开始就有很明确的想法。

比如：

九年，一起学，一起闯，
学过的、练过的，今天接着上场。

我脑海中的画面是：一个人在温暖的台灯下学习。他和书桌只占画面很小的位置，身后是广阔的空间，逐渐浮现出这些年大家学过的技术关键词——编程、算法、数据库、架构……

随后，承载这些知识的纸板慢慢形成阶梯，铺出一条通往 AI 实践的路。这个人带着旧笔记走上去，来到伙伴们身边，一起把想法做成可以使用的东西。

我想通过这个画面表达：过去学过、练过的知识，正在成为今天用 AI 做事的基础。 它也承载了我对极客时间 9 周年的理解——那些独自学习的时刻，最终可以与今天的实践、与一群人的共同努力连接起来。

这些想法给了 AI 创作方向，但要把它们变成连贯的视频，还需要继续明确人物比例、场景关系、动作顺序和镜头节奏。接下来，我便借助 AI，把这些设想逐步拆成分镜、关键帧和可以反复修改的视频片段。

先把风格和人物定下来，再让画面动起来

进入画面制作后，我首先要解决的是：怎样让不同片段看起来属于同一支 MV。

这首歌涉及多个场景，如果每一段都单独生成，很容易出现人物长相变化、服装不一致，或者上一段像广告片、下一段又像动画片的问题。

经过尝试，我选择了真人剪纸拼贴的风格：人物保留真实的表情和动作，轮廓带一圈细白边；背景以钴蓝色为主，搭配橙色、米白色的纸板道具，保留纸张褶皱和瓦楞边缘。

这种风格也天然适合表现歌词里的幽默感——奖杯可以大到挡住人的脸，铅笔可以快有人高，电脑也可以做成巨大的纸板模型。道具的夸张能够放大笑点，而人物仍然保持正常比例和自然反应。

人物也需要固定下来。我为主角设定了卷发、黑框眼镜、白衬衫、黑领带和橙色挂绳，其他同事也分别有明确的发型和服装。后续制作时，将参考图片与这些特征一起提供给 AI，作为不同镜头之间的连续性依据。

我的做法是：先用 ChatGPT 写出分镜脚本，再根据脚本生成关键画面，检查构图、人物和道具是否合适。有些问题在静态图片里就能发现——人物显得太矮，标题不够醒目，或者品牌元素太多、画面太乱。先修改这些问题，再进入视频生成，可以减少一部分后续返工。

从“写一大段提示词”，到“把一个动作讲清楚”

最初，我习惯把整段想法完整写进提示词，希望 AI 一次完成。

例如，有一段 20 秒的视频，需要表现：主角接通工作流程，文件开始自动流转，五个 AI 分工处理任务，遇到问题时交给人确认，最后大家一起试用和修改应用。

这些内容在文字里是连贯的，但生成后，画面往往很热闹，动作之间的关系却不够清楚。前一个动作还没交代完，下一个道具已经出现；有的地方又长时间停住，没有推进故事。

我逐渐意识到：提示词写得完整，并不代表一个片段就能承载这么多事情。

把长片段拆开，给每段一个明确任务

视频生成我用的是即梦。实际操作中，我发现一次塞太多内容进去效果并不好，于是把部分 20 秒片段拆成两个 10 秒片段，把 30 秒的尾声拆成两个 15 秒片段。

拆分时，我会先明确每段要完成什么。比如自动流程这一段，前半段讲“重复工作开始自动运转”，后半段讲“人负责判断和修改”。

这样检查生成结果时也更容易聚焦：这一段有没有把分工讲清楚？那一段有没有表现出人工确认？如果某段出了问题，可以针对这一段调整，不必把所有内容重新生成。

增加中间帧，明确前后交接的状态

只有首帧和尾帧时，中间过程仍然有很大的不确定性。我因此加入中间帧，让 AI 有一个更明确的交接目标。

在自动流程的场景里，中间帧设定为：五个 AI 已经在后方工作，一辆文件车停在桌边等待确认，主角正伸手接取文件，桌上的方案仍然平放。

这个画面明确了两件事：前半段的自动流程已经建立，后半段的人工判断即将开始。

对应的提示词也更具体：

第一段结束时，主角伸手接取文件，桌面方案保持平放。第二段从接取动作继续，依次完成核对、修改和放行，再进入方案试用。界面板和巨型铅笔不要提前出现。

中间帧不能保证所有动作都正确，但它把原本模糊的“自然衔接”，变成了可以直接检查的画面状态。

让动作配合音乐，而不是等音乐结束

这支 MV 既有说唱，也有对白和品牌歌词。我把关键台词的时间点单独列出来，再安排对应动作。

例如，同事询问时看向主角；主角说“来，给你看”时转动电脑；唱到品牌主题时，文字再逐渐显现。视频拆成两段后，还需要把原音轨时间换算成本段时间，避免动作或文字提前出现。

我也遇到过片段最后几秒提前停在尾帧的问题——画面虽然对上了，但人物像在静止合影。

后来，我会明确写出结束前仍在发生的动作：主角转头看伙伴，再看向观众；电脑继续转动；另一只手缓缓展开。到最后一刻，才达到尾帧构图。

做这支视频，哪些地方反复改了好几遍

强调了好几遍“不要错别字”，还是会出错

技术词墙、周年标题和电脑界面，都出现过错别字。我在提示词里反复强调“不要有错别字”，生成出来还是会错。

技术词墙尤其难。我想让几十个关键词铺满背景，大小错落，再让它们随着纸板移动、变成阶梯。静止时看着正确的字，动起来也可能变样。

后来，我开始把文字和动态画面分开处理：先校对关键帧里的文字；标题、关键词和 logo 尽量使用确认过的素材，在剪辑时叠加；电脑界面里不需要读清的内容，就改用图标或无字卡片。

不过，提供了正确的参考图，也不能保证视频里的字一直正确。这些文字还需要在剪辑时逐一核对、替换。

道具关系不清楚，会长出意料之外的东西

有一次，桌面的界面板刚立起来，下方就出现了铅笔尖。

检查参考尾帧后，我发现巨型铅笔正好被界面板遮挡，生成结果像是把笔尖理解成了界面板的一部分。

修改时，我重新安排了顺序：先立起独立的界面板，之后主角从侧面拿起一支完整铅笔，让笔杆、削面和笔尖连续可见，再落到纸面修改细节。

这个问题让我开始关注更具体的空间关系：道具从哪里来，由谁拿起，经过哪里，什么时候被遮挡。相比不断添加“自然、流畅”这样的要求，这些描述更便于明确问题，也更便于检查结果。

生成结果不满意时，先判断该改哪里

反复修改后，我给自己整理了一张检查表。每次生成后，先定位问题，再决定修改提示词、参考图，还是交给后期处理。

每轮先改一个最影响理解的问题。比如人物比例和动作顺序都不对，先修参考图中的比例，再调整动作。否则同时改动太多，很难判断哪一项调整有效。

我还会保留“问题截图＋本轮修改＋重新生成的结果”。这样，下次遇到类似问题，就有具体记录可查，不必重新猜一遍。

这些做法仍然需要逐次验证，但至少让我在点击“重新生成”之前，能够说清楚：这一次要解决什么，准备改哪里，以及怎样判断有没有改好。

一些心得体会

这次经历让我形成了一个更明确的制作顺序：先确定想表达的内容，再固定视觉和人物，通过关键帧明确状态，最后分段生成、检查和修改。

对于第一次尝试的人，我建议先选一个 10～15 秒的小场景，只讲清楚一件事。准备好准确文案、角色参考和风格图片，确定开始与结束的画面；如果中间有明显变化，再加入一张中间帧。

每轮修改优先解决一个主要问题，同时保留失败结果。很多经验正是从这些对比里积累出来的：什么描述太模糊，哪些动作放在一起容易混乱，什么内容需要交给后期准确制作。

制作《AI，落地见真章》的过程，也让我对这个主题有了更具体的感受。

从一个想法到可用的结果，中间需要不断尝试、判断和修正。那些被拆开的镜头、反复调整的动作，以及还在处理的问题——都是“AI 落地”真实的样子。

它不是一句轻飘飘的口号，而是一个需要动手去做、去试、去打磨的过程。

而这，也许就是“落地见真章”真正的含义。

成果展示

视频链接：http://gk.link/a/12MBd

18 使用 AI 依据课程内容高效生成课后测试题

我做成了什么

我是极客时间工程师，负责开发 AI 生成课程测试题目的功能。我们公司的平台上有很多课程，既有图文课程和视频课程，也有引入的第三方课程。现在需要为这些课程生成符合要求的测试题目，用来检查大家的学习效果。我把资料处理、知识点提取和题目生成做进后台，再加入 AI 审题、历史合格题复用及 Excel 导出。业务同事可以按课程配置题型、难度和题量，得到便于复核的试题。题目最终是否适合考试，仍由人工判断。

原来怎么做，为什么值得改变

给不同课程出测试题，首先要解决资料从哪里来的问题。图文课程有正文，视频课程通常需要字幕或课件，引入的第三方课程能提供的材料又各不相同。业务同事需要围绕课程实际讲授的内容，按指定题型、难度和题量准备题目，检查学员是否理解并掌握了相应知识。结果可能导入公司题库，也可能整理成客户平台所需的表格。

需求沟通中，同事介绍过一种具体做法。有些引入的第三方课程只有外部视频，没有现成的源文件或课件，就要边看视频边截取 PPT 画面，再把截图交给 AI。能拿到课件时，资料也可能是图文混排的 Word，或者整页都是图片的 PDF。直接提取文字，会漏掉图里的内容。

生成题目以后还有不少工作。客户要填写每题考核的知识点，业务需要补；公司题库要求关联有效技能，技能为空或名称不存在，就得处理后才能导入。专业词识别错了，错误会从字幕一路传到题干和解析。题目还可能有正确选项明显更长、题干绕得太远等问题。

因此，这个项目需要把从资料输入到题目交付的整套流程组织起来。图文正文、视频字幕和第三方课件都要变成可用于出题的内容，生成结果要符合考核要求，并能方便地检查和导入题库。只让 AI 一次生成一批题目，还会留下整理资料和补字段等大量手工工作。

怎样把 AI 放进出题流程

下面以一门需要使用附件出题的第三方课程为例，说明整个流程。平台中的这类课程也称为生态课。图文课程和已有字幕的视频课程使用各自的可用内容，沿用相同的生成、审题和导出流程。

**先由人确定考核范围。**业务在后台选择课程，设置单选、多选、判断的题量及难度，填写补充要求。生态课可以上传 PPT、Word、PDF 或图片等附件作为出题的资料。附件与课程绑定，后续可以继续使用。业务需要先确认资料属于这门课，是否完整、适合用于考核。

系统会先检查是否有符合条件的历史合格题，可以复用的部分先选入，不足的部分再生成。这样，同一课程重复出题时，已有成果可以继续使用。资料变化以后仍可能复用旧题，因此业务也要留意旧题是否适合新的课程内容。

**接着把资料整理成模型能读的内容。**程序提取文档中的文字、表格和图片，把图片交给视觉模型识别，再按原来的位置组合回文本。原文件与解析结果都会保存，后续不必每次重新识图。这一步需要保住图文的前后关系，避免图片说明离开对应正文。

**资料准备好以后，先让 AI 提取知识点。**模型需要给出知识点名称、说明、考核目标和原文依据。程序检查所引证据是否确实出现在输入段落中，避免模型把常识补充混进课程。长资料分段处理，再合并重复知识点。无效的结果会被排除，并保留原因。

这里的一次调整很关键。知识点被放到生成之前，指导题量分配；每题再关联实际考核的知识点。如果等到导出时才让模型补这一列，就难以判断题目最初是否围绕课程重点生成。

**然后分批生成题目，并做两层检查。**AI 收到知识点及其依据，按题型、难度和要求生成题干、选项、答案、解析以及两级技能。程序先检查字段、选项数量和答案是否合法，再用审题提示词让模型判断答案是否正确、干扰项是否成立、题目是否有资料支持。

审题同时检查术语和表达。能够根据资料修正的题进入修订，修改后再审；无法修复的题被淘汰，系统尝试补足缺额。当前新题最多经过两轮审题，第二轮仍不通过就剔除。修订位置在导出时标红，人工可以据此优先查看。生成和审题可以使用同一个模型，通过不同任务要求组织两次处理，人工复核仍然必要。

**最后处理交付。**系统把本次使用的技能汇总到 Excel 的“技能匹配度”工作表，与现有技能库精确比较，标明“已存在”或“不存在”。缺失技能不阻止导出，也不会被自动创建，业务需要在导入题库前维护。人工检查题目与课程是否相符，并确认答案和技能，之后再交付；特殊客户模板仍可能需要手动调整。

人工、程序与 AI 的分工

人工选课并确认资料 → 程序提取文字与图片 → AI 识图，程序按位置回填 → AI 提取知识点，程序检查证据 → 程序分配题量，AI 生成 → 程序校验，AI 审题及修订 → 程序导出并标红 → 人工复核、维护技能并交付。

存在符合条件的历史题目时，先复用，再对缺额执行资料处理与生成；历史题目也要符合本次配置。

效果怎样判断

这个项目带来的变化，主要体现在出题响应和成本上。过去，为课程准备符合要求的测试题目，需要找熟悉相关领域的专业老师。老师有自己的授课和工作安排，不一定能及时抽出时间，出题需求往往需要等待，聘请老师出题的成本也较高。现在，业务同事准备好课程资料和出题要求后，就可以提交 AI 出题任务，响应更及时，出题成本也更低。

这里按实际使用中的响应及时性和成本变化作定性比较，不列具体金额、耗时或节省比例。题目质量仍要逐题检查，尤其是专业术语、答案正确性和考核范围。遇到无法核准的专业内容，仍需要专业老师介入。

踩过的坑，以及现在的边界

一次真实测试暴露了历史复用的问题。某课程要求生成五选项题，导出的 10 道题里，9 道只有四个选项。追查发现，这 9 道全部来自历史题目，唯一新生成的题符合五选项要求。历史匹配漏查了选项数。随后补上候选筛选和选入时的检查，不符合的旧题跳过，由新题补齐。这个问题说明，旧题曾经合格，也需要满足当前任务配置。

另一个问题是答案位置约束。为了让选项分布均衡，系统给出答案位置计划，但硬性要求模型服从位置，会把候选题反复淘汰。后续改为分布建议，优先保证答案正确和题量。代价也要说清，最终答案分布仍可能偏斜，审题修改还会再次改变分布，这项没有被彻底解决。

模型审过的题也不能直接等同于可交付题。字幕可能含有错误术语，图片识别也可能漏读。原文依据能帮助追查来源，但来源本身仍可能有错。业务反馈的专业名词和英文拼写，需要结合课程材料核对，关键题目应请熟悉内容的人检查。

资料少时，系统允许同一知识点从不同角度出题，但仍要有依据、答案明确。补生成受到次数和执行期限限制，不会无限等待。必要时保留已有合格题，由人决定降低目标题量、补资料或重新发起任务。

如果你也想做类似的事情，可以从哪里开始？

这套方法适合手里有课程资料、需要反复制作用于测评的客观题，并且有人能审核内容的团队。开始前需要准备可使用的课件或文本，明确题型、难度和导出字段，同时安排懂课程的人检查结果。

第一次可以选一段内容完整的小课件，试做 10 道题。这是试用建议，不是本案例的效果样本。先提取知识点和原文依据，人工确认没有脱离课程，再生成、审题、导出。把每一道修改或淘汰的原因留下来，下一次再判断问题来自资料、生成要求还是检查规则。

遇到资料缺失、专业内容无法核准，或者题目需要很强的主观判断时，应先请人工补齐条件。团队最先需要准备的是一套能检查答案的材料，以及愿意逐题看完第一批结果的人。

19 内容中台 AI 化改造：让一份文稿更快成为可发布的内容

先用一段话说清楚，我做成了什么

我们围绕编辑和教研的内容发布工作，把 AI 排版、封面生成和语音合成接入现有内容系统。过去，飞书文稿需要复制到不同后台重新排版，封面要单独找图或生成，音频需要人工整理朗读稿。现在，系统复用文章内容完成这些处理，功能已经上线使用，排版助手省下了一个公众号排版实习生的费用，音频处理每篇从 40 分钟降至 3～5 分钟。编辑仍需检查和微调排版、判断封面是否适合，以及检查朗读稿和选择音色。

原来怎么做，为什么值得改变？

编辑和教研在把文稿转成公众号文章、网站内容或专栏音频时，被反复排版、制作封面和整理朗读稿占用了时间。

文稿写在飞书文档上，要复制到微信公众号、InfoQ CMS 和极客时间后台完成排版和发布，同一份内容进入不同编辑器，需要适配各自的格式。音频又多一道准备工作，编辑先删改图片、代码和表格等不适合直接朗读的内容，再调用语音工具，处理上传、审核和修改。文章封面图需要编辑花费大量的时间寻找合适的配图或者手动使用 AI 工具生成。

以上工作不创造价值却花费了大量的时间。

我具体怎样把 AI 用进去？

**以飞书文稿为起点，按渠道完成排版；需要封面或音频时，直接复用文章内容。**以下按产品文档中的操作顺序展开，不将多个环节虚构成一次已经计时的完整任务。

先解决文稿进入发布后台的问题

为了减少跨编辑器的重复排版，排版助手做成 Chrome 插件，自动识别当前飞书文档，也支持手动输入链接。编辑选择目标平台，公众号内容按选定模板生成草稿，InfoQ CMS 和极客时间则在相应编辑器中填入文章。

模板承担固定格式，编辑在目标后台检查并微调。这样，原稿继续作为内容来源，渠道差异由 AI 排版工具处理。

把封面制作接在文章内容后面

为了减少单独制作封面的操作，系统读取当前文章标题与正文，结合提示词和尺寸要求生成图片，生成后直接上传到课程封面字段里。

编辑不必重新向外部工具描述整篇文章。通用约束保存在 System Prompt 中，当前文章提供主题内容，生成后由编辑判断是否适合使用。截图中的无文字约束，就是把常见要求提前写进生成条件的例子。

先把文稿变得适合听，再合成语音

原文中的代码、图片和表格无法朗读，机械的朗读，仍需要人处理。为解决这一步，极客时间在原文章中增加独立的朗读稿字段，用规则处理与大模型处理生成中间稿，再交给语音合成工具。现在的步骤是：

1. 编辑先保存专栏文章，系统依据已有素材生成朗读稿，保留原始正文。AI 的处理比如：保留 Redis、Kafka、API 等英文缩写和产品名，不要改成中文解释。它把人工检查发现的问题转成下一次生成的明确约束。
2. 编辑花少量的时间检查图片、表格等内容是否转成合适的口头表达，核对英文缩写、产品名和课后思考题，需要时修改或补充要求后重新生成。
3. 选定可用音色后提交任务，系统先保存朗读稿，再在后台生成音频，完成后自动关联当前小节。

这项改动让正文与朗读稿在同一素材下分别维护，取消了专门为朗读稿再建一个小节的做法。AI 承担适听改写，人仍负责检查表达和选择音色，系统接续生成与关联工作。

有没有效果，我是怎么判断的？

功能已经上线使用了，背景中提到的人员成本都节省掉了，且未发生新的成本支持。

哪里不好用，我踩过什么坑？

原稿记录的问题出现在音频制作前。原文中的代码、图片和表格无法直接朗读，机械朗读仍需要人处理。因此，在原文章中增加独立的朗读稿字段，先用规则与大模型生成适听稿，再交给语音合成工具。

处理专业内容时，需要保留 Redis、Kafka、API 等英文缩写和产品名，不要改成中文解释。编辑检查图片、表格是否转成合适的口头表达，核对产品名和课后思考，需要时修改或补充要求后重新生成。

生成结果仍需人工检查。排版在目标后台微调，封面由编辑判断是否适合使用，朗读稿检查通过后再选择音色并合成。

如果你也想做类似的事情，可以从哪里开始？

这套做法适合需要把同一份文稿发布到多个平台，或同时制作封面和音频的编辑、教研团队。准备好原稿、各渠道排版模板、封面提示词与尺寸要求，以及朗读稿处理规则，再接入现有内容系统。

第一次可以选一篇已有文稿，先完成进入目标后台的排版，再按需要生成封面或朗读稿。检查图片、表格和专业术语的处理结果，确认合适后继续使用；存在问题时，由编辑修改或补充生成要求。

最后想分享的话

使用 AI 重构现有文章排版上线流程，把 AI 融入文章排版、封面生成和语音合成中并接入现有内容系统，让编辑从重复搬运和手工整理，转向专注完成内容创作。

20 我用 Agent 造了条文章自动化生产线

案例名称

文章生产线：Claude Code 写作 skill + 自研 publisher-agent 桌面 App，实现技术文章“写作 → 分发 → 排期 → 审核监控”全链路自动化。

案例简介

我是产品人 + SRE 背景的个人技术写作者，在掘金/知乎双平台维护 7 个专栏（FDE 九辩、K8s 深入理解、云原生踩坑实录、SRE 转型路线、SRE 图谱平台全栈实践、R2R × Jev、分布式不难懂）。

写作环节早已和 Claude Code 协作顺畅，但分发环节仍是纯手工：每篇文章要登录后台、填标题摘要、选分类/标签/专栏、制作上传封面、设定时发布、事后盯审核状态，单篇 10 分钟起步，忙起来就断更，断更直接影响专栏的读者粘性。

我用 Claude Code 写作 skill + 自研 publisher-agent 桌面 App（Tauri 2.0 + Rust 核心）搭了一条文章生产线：写作层把惯例沉淀为 skill，分发层免浏览器直连掘金 API 自动发布，运维层用 SQLite 状态机 + 每小时心跳对账 + 自愈做监控。21 天管理 54 个条目、掘金侧 50+ 次全自动发布，全账号累计已发布 76 篇、日均 1.4 篇持续产出，全部零手工分发。

之前的老方案是什么，存在什么问题

写作早已和 Claude Code 协作顺畅，但分发环节纯手工仍然很繁琐，忙起来就断更。拆成四个具体问题：

1. 发布操作重复繁琐：每篇 10+ 步手工操作；
2. 没有排期机制：断更风险高；
3. 平台审核是黑盒：被拒了无法当天发现，错过修改窗口；
4. “哪些已发、哪些待发、哪些被拒”全凭记忆：零可观测性。

本质是把内容当一个一个项目在做，而不是当持续运转的服务在做。这里缺的正是 SRE 眼里的自动化、排程、监控与自愈。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

三层架构，各层独立可用、组合成生产线：

1. 写作层（Claude Code skill）：把写作惯例沉淀为可复用 skill（article-pipeline）：选题 → 大纲 → 成稿 → 修订的流程固化；并把掘金高阅读量文章的标题模式、结构节奏分析结论写进惯例，让数据反哺写作。人机分工明确：人管选题与观点，机器管重复劳动。
2. 分发层（自研桌面 App）：publisher-agent，Tauri 2.0 壳 + Rust 核心，免浏览器直连掘金 API。链路：扫描本地 Markdown（frontmatter 声明元数据）→ 可视化编排（选篇/定时/专栏/标签/摘要）→ 自动创建草稿并发布 → 自动生成 192×128 封面并上传 → 专栏/分类/标签自动匹配。
3. 运维层（SRE 实践）：SQLite 状态机（pending → publishing → in_review → live/rejected/held）、Windows 每小时心跳任务、审核状态自动对账、Cookie 过期自动转 held 并引导重新扫码（自愈）、防重发护栏（已发标题冻结 + 内容指纹去重 + 发布时间闸门）、51 个自动化测试守护核心逻辑。

过程中踩过的坑（踩坑与修复）：

1. 中文标题按字节截断，切在汉字中间直接 panic 崩溃 → 全面改为字符级安全截断；
2. 定时心跳与“立即发布”并发执行，状态互相覆盖“全乱套” → 引入跨进程文件锁；
3. 特定词汇组合（如招聘类词×金额表述）触发内容审核拒绝，相似内容重投会被更快拒绝 → 沉淀预检规则，发布前对标题/摘要自检；
4. Cookie 中途失效，条目卡死在中间态 → 引入 held 状态 + 自动治愈流程；
5. 早期 Python 版依赖本机环境，换机即失效 → 核心逻辑重写为 Rust，状态收进 %APPDATA% 下的 SQLite，App 完全自包含，零环境依赖；
6. 浏览器自动化有边界：Webview 内嵌 Chrome 方案失败，知乎接口反自动化强 → 诚实降级：掘金全自动，知乎保留“一键半自动”，不硬造全自动假象。

与旧办法相比，新办法的结果如何（数据对比）

（数据来自数据库 + 掘金创作者中心实测，非估算）

• 生产端：21 天（9/18–10/9）状态机管理 54 个条目，掘金侧 50+ 次全自动发布；全账号累计已发布 76 篇、创作第 56 天——日均 1.4 篇的持续产出，全部零手工分发。
• 专栏矩阵（全部由该工作流创建并维护）：7 个专栏 62 篇——FDE 九辩（11）、K8s 深入理解（14）、云原生踩坑实录（12）、SRE 转型路线（9）、SRE 图谱平台全栈实践（8）、R2R × Jev：判断之后的治理（5）、分布式不难懂（3）；专栏文章数与逐篇 API 核对结果完全吻合。
• 传播端（掘金数据看板 10/9 读数）：文章展现 60,287 次、阅读 2,150 次、点赞 34、评论 11、收藏 19。
• 单篇明细（API 核对 62 篇）：Top3 为《消息队列选型决策树》127 读、《云原生 SRE 巡检图》105 读、《FDE 人才定级手册》97 读；Top10 合计约 820 读、占总阅读 37%，多系列铺量的长尾结构清晰。
• 可审计：494 条事件流水，每次状态迁移可回溯。
• 单篇分发操作从 10+ 分钟 → 0 分钟（加入编排即完成）；
• 审核状态从“想起来才看”→ 每小时自动对账，被拒当天可见；
• 断更风险消除：一次编排多日排期，心跳自动执行——10 月 9 日当晚心跳仍在自动发文。

意外收获：写作 skill 与发布 App 形成双向闭环——发布侧经验（过审标题、高阅读结构）回写进写作惯例。

通过这个 AI 落地案例，我的收获有哪些

1. Agent 工程的核心是状态机而非提示词：把“发布一篇”建模成显式状态机后，每种异常都有了挂靠点；
2. 防重发比发布本身更重要：平台风控不可控，护栏（标题冻结、指纹去重）是敢让系统无人值守的根基；
3. 诚实降级好过硬造全自动：明确声明半自动边界，反而让全自动部分更可信；
4. 人的判断留在选题与观点，机器接管重复：这条线划清楚，人机协作才顺畅；
5. SRE 方法论（排程、对账、自愈、自检）适用于任何“要持续运转的个人系统”：个人开发者也配拥有生产级运维。

21 694 道题背后：一条 AI 内容校验流水线如何运转

案例名称

西门子 S7-200 SMART 备考题库平台：五级可信度流水线（抓取→出题→打包→前端资产→答案校准）+ 运行时闸门，产出 694 道高置信题与 22 章讲义。

案例简介

我是产品人 + SRE 背景的个人开发者，为西门子 S7-200 SMART 认证备考做了一个完全离线、零遥测（首启 EULA 明示承诺）的 Windows 桌面题库平台：Tauri 2 + Vue 3.5 前端约 3300 行，Rust 后端约 2967 行、12 个领域模块，题库/用户双 SQLite。起点只有 5 套挂在问卷星的在线模拟卷和西门子官方文档（系统手册 V2.8、技术参考 PLUS 2.6、选型手册 V2.8，共 2000 余页）。

14 天、52 个提交跑完从抓卷到可分发安装包的全流程：694 道题（344 题库题 + 5 卷 350 题真题）与 22 章讲义由多智能体流水线生产，6 层 22 节点技能树经机械校验把关。平台供开发者个人学习自用，并分享给同一培训班级的同学共同使用——使用者就是要上考场、目标拿到西门子初级证书的人。对这类内容产品，生死线不在“生成”而在“可信”：题库答案错一道，就是在误导一个要上考场的考生。

之前的老方案是什么，存在什么问题

备考西门子初级证书的传统解法是“三件套”：纸质/在线题册刷题、有人整理的模拟卷、自己啃手册。AI 介入前的现状就是项目起点——5 套问卷星在线模拟卷 + 2000 余页官方手册，弊端都藏在日常里：

• 题目散、只能在线刷：题目按「卷」组织而不是按知识点组织，想专项补弱（比如 PID）只能整卷重刷；做错的记录留在当次提交里，沉淀不出错题本，更没有复习调度——遗忘全凭感觉。
• 答案对错无人负责：在线卷官方判分给什么就背什么，没人会为 70 道题去翻 2000 余页手册逐条验证——B 卷第 10 题“1 个 WORD 包含多少个 BYTE”，官方判分给 C（4），手册 9.18 节（页 450）写明是 2，这种冲突在传统模式里根本不会被暴露，只能被原样背进考场；纸质题册更糟，答案印错就只能一直错，连勘误渠道都没有。
• 资料整理是纯手工活：把考点从 2000 余页手册里摘出来做讲义笔记，靠人工摘抄、以周计；整理完也没有可检验的学习路径。
• “自己做一套题库工具”在经济上不成立：人工从语料出几百道题、逐题校对、再写数万字讲义并逐条核对出处，是以月计的专职工作量。

弊端归结为一句话：传统方式里没有任何一层校验——题册答案对错没人负责，学习路径覆盖是否完整没人验证，做题记录无法沉淀成复习调度。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

一条五级可信度流水线，编号即生产顺序（1x 抓取 → 2x 题库生产 → 3x 打包 → 4x 前端资产 → 5x 答案校准），外加一道运行时闸门；背后是一条权威链——AI 标注答案 < 官方判分答卷 < 带页码的官方手册 < 可机械验证的事实，每推翻一层都留痕：

1. 多代理出题：10 个出题代理从真题卷与官方语料生产 344 道题库题（全流程合计数十个代理）；
2. 对抗校验：15 个校验代理背靠背逐题裁决，产出 corrections.json（20KB）裁决记录，每条含 verdict + 手册出处引文——“检查过”必须落在可审计的数据上，而不是一句结论；
3. 官方满分卷校准：以问卷星官方判分答卷（5 卷 × 70 题全对，350/350）为外部基准逐题比对：276 题一致 → 置信度升为 high；74 题不一致 → 以官方判分为准修正，corrected_from 留审计字段；原 57 道待复审试卷题随之全部转正，全库 694 题皆高置信；
4. 手册裁决：对官方判分与西门子手册冲突的 14 题，按手册页码逐题引证，answer 取手册口径、official_answer 存档原官方答案，双口径并存并明示取舍——技术事实以可翻书复核的手册为准，应试信息双口径披露、取舍权交给考生；
5. 机械核对 + 运行时闸门：讲义 108 条出处引用由脚本机械核对，96 条精确文件名全部命中，其余 12 条目录级引用逐一人工确认指向真实目录；技能树过五项机械校验（22 章不重不漏、每层 2~5 节点、DAG 无环、快速路径闭合、估时自洽）；AI 标注答案附置信度，低置信不计分；判分权威实现唯一在 Rust，交卷重算即信任边界。校准成果以种子包 v1→v8 版本化发布，每一级可追溯。

过程中踩过的坑：

1. AI 内容的可信度不是“生成”出来的，是流水线做出来的——每一级校验都要留下可审计产物（verdict、corrected_from、official_answer、脚本核对清单），而不是一句“已检查”；
2. 对抗校验必要但不充分：多代理互查之后，对官方满分卷仍有 74/350 不一致；而任何“用 X 校准 AI”的方案都要先回答：X 自己的错误率是多少、X 错了怎么被发现——满分卷自身也有 14 题与手册冲突，没有这一问，校准只是把错误换了个人来背书；
3. 权威是分层的，不是二元的：带页码的手册 > 官方判分 > AI 标注；但考试计分又依赖官方口径——冲突时双口径存档、把取舍明示给用户，比替用户黑箱选边诚实得多；用户要的不是“唯一的正确答案”，是“不被误导”；
4. 引用核查交给确定性脚本，不交给模型自觉：“零编造”是逐条查出来的，不是承诺出来的；
5. 可信度不是一次性成果而是持续属性：旧种子降级覆盖能静默回滚校准成果，版本护栏与自愈就是可信度的“运维面”——对 SRE 是常识，对数据流水线同样成立；诚实标注边界本身也是可信度的一部分：低置信答案不计分，没有使用数据就承认没有。

与旧办法相比，新办法的结果如何（数据对比）

• 交付：从 14 天的耗时变成当天完成（12:00–19:14 跑完抓卷→解析→出题→资料生成→初始提交，当天 17 个提交）。
• 答案质量：694 题（344 题库题 + 5 卷 350 题）全库高置信——276 题校准一致升 high、74 处按官方判分修正（corrected_from 审计字段全程留痕）、原 57 道待复审题全部转正；14 题按手册裁决（每题附手册页码引证、双口径存档）；答案校准链 4 个提交（种子 v2→v5）在 08-31 当日完成，可逐一回溯。
• 内容资产：22 章讲义 108 节约 4 万字，出处引用零编造（96 条机械命中 + 12 条非标准格式人工核对确认）；技能树经五项机械校验；产品形态闭环覆盖「快速进入学习状态」（讲义/技能树/五板块速查）与「不断考试练习检验效果」（7 种练习模式/整卷考试模拟/SM-2 间隔复习/错题本/掌握度视图）。
• 工程：19 个 Rust 测试 + 8 个 Playwright E2E 套件，最终提交 CI 双 job 全绿；免安装便携包 11.2MB 含全部题库与语料。
• 开源：代码开源（github.com/Thneoly/s7-smart-quiz），数据与代码分离，克隆者自备 .smartbank/.docpack 即可复用全部功能。
• 使用侧：开发者个人学习自用，并分享给同一培训班级的同学使用；零遥测承诺下无使用数据采集，使用情况为人工口径、不附量化数字。

通过这个 AI 落地案例，我的收获有哪些

1. 可信度需要一条独立于生成、逐级留痕、可回溯的校验流水线：对于“答案错一道就是在误导考生”的内容产品，校验不是生成环节能“顺便”解决的。
2. 校准任何 AI 之前先问“基准自己的错误率”：满分卷自身也有 14 题与手册冲突——没有这一问，校准只是把错误换了个人来背书。
3. 分层权威 + 双口径披露 + 引证可复核：这套方法可直接迁移到通用 RAG / 知识库类 AI 应用：多源知识冲突时，一份带出处的分歧报告，比一个自信的单一答案更接近可信。

22 把闲置的 GPU 变成一台「内容印钞机」：怎么用 AI 帮一家景区把宣传视频从一周压到一天

一个算力租赁公司的真实落地故事。只讲我们怎么把智算中心里闲置的显卡，变成文旅客户手里能直接用的生产力。

先用一段话说清楚，我做成了什么

我是某算力服务公司的平台产品负责人，日常需要把公司智算中心里成千上万张 GPU 卖出去、用起来。过去我们卖算力，本质上就是卖“裸资源”——客户租走一张 A100 或者开一台 GPU 开发机，至于拿它干什么、能不能干成，我们管不着，也帮不上。主要问题是：算力是“半成品”，客户拿到卡之后还要自己搭环境、调模型、写工作流，门槛高得吓人，大量中小企业根本用不起来；而与此同时，我们自己机房里又有大把空闲时段在“空转烧电”。

从去年 8 月份开始，我尝试用一套自研的多模态内容生成平台去辅助客户完成“从想法到成片”的内容生产——底层跑在我们智算中心的闲置 GPU 上，简单任务用 ComfyUI 编排工作流，复杂任务用 Agent 编排。经过半年多、服务了一家文旅景区客户的高频使用，目前的结果是：景区客流统计口径下增加了约 20%，一条宣传视频的制作周期从原来约一周压缩到不到一天，效率提升接近 10 倍。其中仍需人工完成的是：最终内容的审核把关、品牌调性的判断，以及涉及具体景点事实的核对。

原来怎么做，为什么值得改变？

我们公司的主营业务是算力租赁，产品形态主要有两种：一种是 GPU 裸机租赁，客户整台整台地租服务器，自己装驱动、自己配环境；另一种是云平台 GPU 开发机，客户在我们平台上按小时开一台带显卡的虚拟机，用完就关。这两种产品的共同点是：我们只交付“算力”，不交付“结果”。

这套模式对大厂是成立的——人家有算法团队，租卡就是租卡。但对绝大多数中小客户，尤其是文旅、零售、本地生活这类传统行业客户，问题就来了：他们知道自己需要“AI 做内容”，但不知道从哪下手。让他们从零搭一套 Stable Diffusion 环境、再自己摸索 ControlNet、LoRA、工作流节点，基本等于劝退。

最麻烦的一步，不是“没算力”，而是**“算力到内容之间那条又长又陡的路”**。具体到文旅客户，他们的真实任务是这样的：

一家景区，每周（旺季甚至每天）都要产出宣传素材——今天要一条抖音短视频，明天要一组朋友圈打卡海报，后天要给某个汉服活动做一批“游客换装”的互动图。以前他们的做法是：外包给广告公司或者 MCN。流程是——景区提需求 → 广告公司出脚本 → 约拍摄团队进景区实拍 → 后期剪辑调色 → 甲方反复改 → 交付。一条像样的宣传视频，从提需求到成片，大约要一周，费用从几千到几万不等。

这里最要命的三点：

1. 慢。景区宣传讲究“蹭热点”，一个节气、一场活动、一次天气奇观（比如云海、雾凇），窗口期可能就两三天。等外包团队拍完剪完，热度早过了。
2. 贵且不稳定。外包按条计费，多产出就多花钱；而且质量高度依赖具体对接的摄影师和剪辑师，换个人风格就变，品牌调性很难统一。
3. 改不动。甲方想改一句文案、换一个镜头，都要走一遍“提需求—返工—再交付”，沟通成本极高。

如果不解决，影响很直接：景区的宣传能力被“预算”和“周期”死死卡住，一年就那么几条片子，根本跟不上短视频时代的更新节奏。而对我们算力公司来说，影响同样直接：客户租了卡也不知道怎么变现，续费率上不去，机房的电费却一天没停过。

我们想改变，本质上是因为看到了一个错位：一边是我们手里闲置的算力，一边是客户手里做不出来的内容。中间缺的不是算力，是一层“翻译”。

我们具体怎样把 AI 用进去？

我们这套平台其实服务的是两类完全不同的用户，对应两套彼此独立的能力。 不把它们混成“一条流水线”：

• 第一类用户，是文旅 App 里的 C 端游客。 他们用的是多个互动工作流：比如拍照打卡、一句话修图、服饰写真、一句话 Vlog 等。游客这次可以使用拍照打卡工作流生成一张打卡照，下次可以使用一句话修图工作流修改一张图。
• 第二类用户，是文旅企业的运营维护人员。 他们要的是一句话生成宣传视频，用来发到各大平台做官方宣传。

为了讲清楚，我先把平台的分工画出来：

可以看到，两条业务线从入口到工作流都是分开的，只在最底层的“算力池”汇合——它们共用的是同一批闲置 GPU。下面分开讲。

先说 C 端：互动工作流

这四条工作流都跑在 ComfyUI 上，面向同一批游客，但彼此独立、平行可选。我按“游客点进去会看到什么”来分别讲。

工作流一：拍照打卡。 游客站在园区点位，系统把他的照片和景区实景融合，生成一张“穿越感”打卡照。ComfyUI 里的链路是：输入游客自拍 → 抠图 → 场景融合（用景区实景做底）→ 风格化 → 输出带景区 Logo 的成片。我们发现，纯自动的结果在“人脸和场景的光照匹配”上偶尔会翻车（比如阴天的人脸贴到晴天场景里，看着很假），于是固定了一个“光照一致性”节点，并给现场留了手动微调入口——不满意可以一键重跑。

工作流二：一句话修图。 这是几个里使用频率最高的。游客随手拍的照片往往构图歪、光线暗、背景乱，我们的链路是：输入原图 + 一句自然语言指令（比如“把背景换成银杏林，天调亮一点”）→ 语义解析 → 对应编辑节点 → 输出。我们发现，指令越模糊，AI 越容易乱改（比如只说“好看点”，它可能把整个色调都变了），于是在产品层面加了一层“指令引导”——给用户几个预设句式按钮，降低表达门槛。

工作流三：服饰写真。 汉服节期间，景区想让游客体验“穿汉服在景区拍照”，但真租汉服、真请摄影师成本太高。链路是：上传游客正脸照 → 保持人脸特征 → 换上汉服 → 融入景区场景 → 生成一组写真。这里最关键的是人脸一致性，不能让 AI 把游客换成另一个人。我们发现换装类生成最容易“脸崩”，尤其在侧脸、戴帽子、光线复杂时；于是做取舍：宁可牺牲一点服装华丽度，也要保证脸是本人，并明确告知用户“这是 AI 生成效果图”。

工作流四：一句话 Vlog。 游客输入一句话，比如“做一条 15 秒的银杏林秋日氛围短片”，系统自动从素材库里挑镜头、配转场、加字幕、配 BGM，输出一条成片。我们发现自动剪辑的“节奏感”和“情绪”经常不到位，所以保留了人工环节——用户可以替换镜头、调整顺序。

这些工作流的共同特点是：面向 C 端、即时互动、单个任务轻量。

再说 B 端：独立的一条“宣传视频”能力线

文旅企业的运营维护者，需要的是官方宣传视频——发到抖音、视频号、小红书这些平台做品牌宣传。这是另一条完全独立的能力线，和上面的 C 端工作流没有关系，服务的是不同的人、解决的是不同的痛点。

以前一条宣传片要外包一周，现在运营人员输入一段需求描述（比如“做一条 60 秒的景区秋季宣传片，突出银杏和汉服，风格温暖治愈”），Agent 会：

1. 理解意图，拆解成“脚本 → 分镜 → 素材匹配 → 旁白文案 → 合成”几个子任务；
2. 生成脚本和分镜，给出每个镜头的画面描述；
3. 调用素材库和生成工作流，为每个分镜准备画面（能用实拍素材的用实拍，缺的用 AI 生成补）；
4. 生成旁白文案，配 TTS 语音；
5. 合成输出，交给人审。

它给出的结果是：一条 60 秒宣传片的初稿，从输入需求到可看，不到一天。我们发现，Agent 在“分镜和素材匹配”上省掉了大量人工，但在“事实准确性”上完全不能信——它会一本正经地编造景区没有的设施、错误的开放时间。于是加了一条硬约束：所有涉及事实的内容（地名、时间、票价、设施），必须由人工核对后才能发布。

为什么不用 Seedance2.x 这类更强的模型？

这里一定会有人问：现在 Seedance 2.x 这种视频生成模型效果那么炸，你们为什么不用，反而去搭 ComfyUI 工作流？

原因有三层，而且和我们的立身之本直接相关：

第一，我们本身就是卖算力的。 我们的成本优势来自自家智算中心的闲置 GPU，而不是来自某个外部 API。如果核心生成能力全押在第三方闭源模型上，等于把成本和命脉都交给了别人——那我们就又变回“卖裸算力”了，只不过这次是替模型厂商卖。

第二，ComfyUI 工作流已经能满足客户的真实需求。 文旅宣传要的是“稳定、可控、风格统一、能批量出”，而不是“每一条都惊艳到拿奖”。ComfyUI 的可编排、可复用、可微调，恰好匹配这种工程化、可预期的生产需求。Seedance 2 单条效果确实强，但它更像“抽卡”——风格一致性、可控性、批量成本，都不是为这种场景设计的。

第三，也是最重要的：能帮客户把成本真正降下来。 用我们自己的闲置算力跑 ComfyUI 工作流，边际成本极低；而调用顶级闭源模型按次计费，量一大成本就失控。对文旅这种“要持续、高频产出”的客户，便宜的、够用的、稳定的，永远比贵的、惊艳的、不可控的更值钱。

一句话总结：我们不是做不出更炫的效果，而是这笔生意里，“成本可控 + 需求够用”比“单条最强”更重要。 这恰恰是我们作为算力公司的差异化——把算力成本优势，转化成客户的内容成本优势。

这一步，也是我们和纯工具型产品最大的区别：我们不是给客户一堆模型，而是给客户一条“从想法到成片”的流水线，人只需要在关键节点做判断。

有没有效果，我是怎么判断的？

先说清楚：这不是一次尝试，而是已经持续使用了半年多，服务的主要就是那家文旅景区客户，旺季几乎是每天在用。

关于“客流增加 20%”这个数字，我要诚实说明它的口径：这是景区自己统计的客流数据，对比的是使用平台前后的同期（我们会尽量对齐节假日、天气等变量，但无法做到严格的 A/B 对照）。所以更准确的说法是：景区方观察到，在宣传物料更新频率大幅提升后，客流统计口径下增加了约 20%。这里面有多少直接归因于 AI 内容，多少来自其他运营动作，客观上没法完全剥离，我不想夸大。

关于效率，这个比较更扎实一些：一条宣传视频从提需求到成片，原来大约要一周；现在从输入需求到可看的 60 秒宣传片初稿，不到一天，其中已经包含人工审核和修改的时间。

需要说明的是，“不到一天”里已经包含了人工审核和修改的时间。我们不是把时间从“一周”压缩到“AI 一秒出片”，而是把最耗时的“拍摄—外包沟通—返工”环节，换成了“AI 出初稿—人工审核”环节。真正省下来的，是初稿整理和外包协调的时间；而事实核对、品牌调性把关，仍然由人完成。

前后任务的难度和质量要求是接近的——都是景区对外发布的正式宣传物料，标准没有降低。这点我觉得很重要：我们不是靠降低质量来换速度的。

哪里不好用，我踩过什么坑？

坑非常多，挑几个真实的讲。

第一个坑：一开始我们以为“给客户一个 ComfyUI 界面”就够了。 结果发现，客户根本不会用。ComfyUI 那套节点连线，对技术人是玩具，对景区运营是灾难。最初的方法为什么没奏效？因为它把“使用门槛”从“租卡”转移到了“搭工作流”，等于没解决。 后来我们才想明白：客户要的不是工具，是封装好的、点一下就出结果的功能。于是我们花大力气把常用工作流产品化，做成“打卡”“修图”“写真”“Vlog”几个傻瓜按钮。

第二个坑：AI 会一本正经地胡说八道。 最典型的一次，Agent 生成的宣传片旁白里，写了景区一个根本不存在的“玻璃栈道”，还配了对应的 AI 生成画面。这条片子如果直接发出去，就是虚假宣传。我们是怎么发现的？ 幸好发布前有景区运营人员逐句核对，一眼就看出来了。从那以后我们定了死规矩：事实性内容一律人工核对，AI 生成画面必须标注或使用真实素材。

第三个坑：人脸一致性翻车。 写真功能上线初期，有游客反馈“这不是我”。我们排查发现是侧脸和复杂光照下的特征丢失。为了稳定，我们增加了约束：限定输入照片的角度范围、在界面上引导用户上传正脸清晰照、后台加人脸相似度阈值，低于阈值就提示重拍。

第四个坑：算力调度和成本。 一开始我们没做精细调度，高峰期游客一多，生成队列排长队；闲时 GPU 又空着。后来我们做了按需调度 + 优先级队列，把非实时的批量任务（比如一次生成一批写真）放到闲时跑，把实时互动任务（打卡）优先保障。这其实正好呼应了我们的主业——用闲置算力做内容，本身就是一笔划算的账。

什么情况下我们仍然选择人工处理？ 三类：一是涉及事实和合规的内容，必须人审；二是品牌核心物料的最终定稿，AI 只做初稿；三是需要强创意、强情感表达的片子，AI 目前还替代不了导演的判断。

如果你也想做类似的事情，可以从哪里开始？

这个方法适合手里有算力资源、但客户不知道怎么用的团队，或者有大量内容生产需求、但外包成本高周期长的行业客户（文旅、零售、本地生活、电商都适用）。在有一定算力基础、能接受“AI 出初稿 + 人工把关”流程的条件下使用效果最好。

开始前需要准备三样东西：一是结构化的素材库（客户自己的真实素材，越具体越好）；二是把常用工作流封装成傻瓜功能（别指望客户学 ComfyUI）；三是一条明确的人工审核红线（哪些内容必须人看）。

第一次尝试，建议先拿一个“低风险、高频次”的小任务练手，比如“一句话修图”或者“打卡图生成”——它不涉及复杂叙事，出错了影响也小，最适合验证整条链路。

遇到涉及事实陈述、品牌定调、对外正式发布的情况时，必须人工介入；遇到需要真实拍摄才能体现的独特体验时，AI 暂时也不适用，别硬上。

最后，我想分享给大家的话

做这件事之前，我一直觉得我们卖的是“算力”。做完之后我才明白，客户从来不为算力买单，他们为“结果”买单。

我们真正的产品，不是那一排排 GPU，而是把闲置算力翻译成客户能用的内容的那层“翻译器”。GPU 是原料，ComfyUI 是流水线，Agent 是车间主任，而人，是最后那个按下“发布”按钮的决策者。

如果你也在做 AI 落地，别急着证明 AI 有多强，先想清楚它替客户省掉了哪一步最痛的事。找到那一步，把它做扎实，剩下的自然会来。

23 3 小时，把一本书变成一套带货图文

先用一段话说清楚，我做成了什么

我是大霞，一个人做内容，日常需要为社科类书籍做微信视频号的图文带货——一本书要产出一套能挂购物车的图文卡片。过去采用“读完书再凭感觉挑金句、一卡一卡写文案、再一张张排版”的方式，主要问题是一本书的内容要反复消化才能下笔，最慢的是把书里的观点拆成九张卡，以及逐张调排版。从 2026 年 10 月开始，我尝试用「大霞图文坊」辅助完成从素材整理到成品卡片的全流程。经过 1 个月、每周 4 本的使用，目前的结果是单本书从素材到成品卡片的耗时从 3 天降到 4 小时，其中仍需人工完成的是原文核对、热点事实核查和挂车文案的最终把关。

原来怎么做，为什么值得改变？

这项任务由谁完成，多久发生一次？

我自己。做视频号图文带货，内容更新频率直接决定曝光和成交，基本要求每周能上新 2～3 本书，每本出一套九图卡片。没有文案、没有设计，全是一个人。

原来的工作流程是什么？

拿到一本书 → 翻目录、读重点章节、划金句 → 想这套卡从什么角度切 → 找一个能勾人的开头 → 一卡一卡写图上文字 → 打开设计工具，九张图逐张排版 → 检查 → 挂车发布。

最麻烦的是哪一步？

两个地方最卡：

一是把书拆成卡。一本书几十万字，要挑出能被划走前看完的九段话，光挑就要来回翻好几遍；挑完还得改写——原文太长、太学术，直接上图根本没人读。

二是排版。九张卡的尺寸、字体、配色要统一，手机上要看得清。而且我经常改完文案发现字号撑爆了，又得重调。

如果不解决，会产生什么影响？

一周最多磨出一本书的图文，上新速度跟不上，账号活跃度掉；更现实的是，看到别人一天铺好几本，我只能干着急——不是不知道该怎么做，是做不过来。

一次具体任务的情况：

有次要给《技术陷阱》做一套带货图文。这本书讲的是技术变革对就业和收入的影响，观点密集但学术气重。光是把核心论点挑出来、改写成九段口语化的图上文字，就花了一整个下午；第二天又花大半天排版、反复在手机上看效果。两天才出一套，其中真正有价值的判断其实不到两小时，剩下的时间都耗在重复劳动上。

我具体怎样把 AI 用进去？

下面以**给《技术陷阱》做一套视频号图文带货卡片（九图 + 挂车文案）**为例，按实际发生顺序写。

第 1 步：素材归集与原文金句库

这一步是我最不愿意省的一步。后面所有 AI 输出的可信度，全押在这份带页码的金句库上。

第 2 步：找钩子——用真实可核验的事件开头

实际使用的提示词（脱敏版）：

你是一名图书内容策划。这本书的核心主张是：【一句话概括】。

请给出 5 个可作为内容开头的钩子，要求：

1. 必须是真实发生、可公开查证的事件或现象，禁止虚构

2. 每条必须写清：时间、主体、具体发生了什么、可在哪里查到

3. 钩子和这本书的观点的关联点，一句话说明

4. 不要用“你是否曾经……”这类抽象痛点开头

如果某个事件你无法确认真实性和出处，不要输出它。

第 3 步：一次性拆出九张卡的文案

为什么强调“一次性出九张”？ 我最早是一卡一卡问的，结果九张卡语气忽高忽低，读起来像九个人写的。改成一次性输出 + 固定结构模板后，整套卡的节奏才连贯。

第 4 步：批量出卡（这一步是提速的关键）

为什么这一步省得最多？ 原来九张卡要逐张调字体、调对齐、调配色、逐张导出，现在一次性批量生成；改稿同理——改文字重出一次就好。真正耗时的“手上功夫”被压缩掉了。

第 5 步：挂车与发布

有没有效果，我是怎么判断的？

这是图文带货最直观的收益：

需要讲清楚的几点：

· 这是一次尝试，还是已经持续使用？ 已持续 2 个月，累计产 4 套图文 / 覆盖 4 本书。

· 比较涉及多少次任务？ 4 套，同类型社科书，卡片结构一致。

· 前后的任务难度和质量要求是否接近？ 同为社科类图书、同为九卡结构，验收标准未变。

· 时间节省是否包含人工检查和修改？ 包含。上面的耗时是从拿到书到挂车发布的全流程，含原文核对和改稿。

哪里不好用，我踩过什么坑？

坑 1：AI 会编金句，而且编得比真的还像真的。

这是我最严重的一次翻车。它给《技术陷阱》写了一句“作者指出：……”，读起来非常地道，我差点直接上图。后来回书里翻，这句话根本不存在——是把作者的观点用另一种说法“重写”了一遍，本质上是我没提供的表述。

图书带货出这种错是要命的：读者买了书发现对不上，评论区一句“文案是编的”，前面所有内容的可信度全废。

我的解决办法就是第 1 步那份带页码的金句库：提示词里写死“只能使用金句库中的原文”，输出后逐条比对，库里没有的一律删。宁可少用一句，也不用一句假的。

坑 2：AI 会编造“真实事件”。

第 2 步让它给可查证的钩子，它给过一条“某企业在某地裁员 XX%”，时间地点数字一应俱全。我去搜，搜不到。后来加了硬约束：说不出出处的就不要输出；即便说了出处，我也逐个去核。

坑 3：一卡一卡问，整套卡的语气是散的。

最早图省事，一张卡一次对话。结果九张卡读下来像九个人写的，前面的钩子很口语、中间突然学术起来。教训：成套内容必须一次性生成，并且先固定好结构模板。

坑 4：电脑上看着挺好，手机上根本读不完。

桌面预览觉得字号合适，发到自己手机上一看，划过去根本来不及读。后来给图文坊的模板加了硬规则：每张图上文字不超过 300 字，正文必须带底衬或描边。

教训：图文带货一定要在自己手机上划一遍再发。

坑 5：什么情况下我仍然选择人工处理。

• 书中原文、金句——一律人工摘录并标注页码，不让 AI 生成
• 涉及价格、活动、发货、售后的挂车信息——全部我自己写
• 涉及医疗、养生、投资建议类的书——AI 特别容易写出功效或收益承诺，这类内容我人工过两遍

如果你也想做类似的事情，可以从哪里开始？

这个方法适合做视频号图文带货、需要持续上新内容的人，尤其是没有团队、一个人扛全流程的个体创作者。在你愿意先把书里的原文踏实摘一遍的前提下效果最好——如果指望 AI 替你读书、替你造金句，这套方法不成立。

开始前需要准备三样东西：

1. 一份带页码的原文金句库（这比任何提示词都重要）
2. 一个固定的九卡结构模板（钩子卡 → 冲突卡 → 观点卡 ×5 → 金句卡 → 引导卡）
3. 一个可查证的时事素材库，用来做开头钩子

第一次尝试，建议先拿一本你已经做过的书重做一遍。因为你对它的内容最熟，能立刻看出 AI 哪里在瞎编，也能真实对比出耗时差异。不要一上来就拿一本完全没读过的书练手——你判断不了 AI 给的是真是假。

遇到原文引用、价格活动、功效或收益承诺这类情况时，必须人工介入；如果你手上的书连自己都没翻过、也查不到官方资料，这套方法暂时不适用——AI 会把模糊的信息加工成看起来很确定、实际不靠谱的话，而带货内容的信任成本，你赔不起。

我以前最焦虑的不是写不出来，是“知道这本书值得做，却要花两天才做得出一套图”。把重复劳动交给流水线之后，省下来的时间我并没有用来多躺一会儿，而是拿去多读几页书、多核几条原文。带货内容到最后拼的不是出图速度，是读者信不信你。 这点 AI 帮不了我，但它把让我去做好这件事的时间，还给了我。

24 别上来就让 AI 写：一个知识工作者的五步工作法

作者按：

资料散在七八个地方，材料总在重写——我怎么用 AI 帮自己查资料、写初稿？

我在公司里做的大多是知识类工作：找资料、写材料、出总结。这篇讲的是我怎么把其中最磨人的几步交给 AI，以及哪些事我还是坚持自己来。

先用一段话说清楚，我做成了什么

我在企业内部做知识类工作，每天要查资料、写各种材料：项目总结、会议纪要、FAQ、操作手册、汇报，还有通知邮件。以前全靠手工，在文档、Wiki、群聊、邮件和内部系统之间来回搜，复制下来，去重、归类，再从头写。这样做很慢，质量看当天状态，写过的东西下次也很难直接拿来用。

后来我开始让 AI 帮我做检索、归纳、排结构、起草和改格式这些重复的活。用到现在，一份材料 AI 大概能先搭出七成左右的初稿框架，整理资料和写东西花的时间少了不少，结构也比以前稳定，漏掉的信息变少了。需要我自己做的，是核对事实、数字和口径，决定最后怎么措辞、突出什么，以及对外发出去之前的审核。

原来怎么做，为什么值得改变？

这类活几乎每天都有。拿写项目总结来说，以前我得先去飞书文档、Wiki、表格、群聊、会议纪要、内部系统和历史项目材料里一个个搜关键词，打开看是不是相关；有用的片段复制到一个临时文档里，手动去重、分类、排顺序；然后看写给谁，技术说明要改成业务能看懂的话，长文档要压成几段摘要；最后还得比较几个版本的发布时间、作者和上下文，确认哪份才是最新的口径。

真正费时间的是动笔之前：找资料和理资料。资料分散在好几个系统里，光切换和搜索就要花很久；找到以后，还要判断哪些是最新的、哪些能引用、几份文档之间说法哪里不一样。重复劳动也多：需求说明、项目总结、FAQ、操作手册、汇报、邮件通知，结构都差不多，每次还是得重写。同一件事讲给技术、产品、运营和领导听，各自关心的点不一样，常常要改好几个版本。偏偏这些需求又经常很急，要求短时间内给出清楚、准确、能直接照着做的答复。

时间大多耗在前面的查找和整理上，留给思考和判断的时间就被挤掉了。材料写得好不好，很大程度看个人经验和当天状态；模板全靠自己攒，更新不及时，也覆盖不全，换个人接手，很多经验就接不上了。

我具体怎样把 AI 用进去？

我给自己定的规矩是：判断我自己做，AI 只负责检索、归纳、排结构、起草和改格式这几样重复的活。下面还是用“把分散的资料整理成一份项目总结”来举例，按我实际的顺序说。

第一步，先把要做的事交代清楚。

开始之前，我会先想明白这次是查信息、写材料、做总结、出报告，还是帮忙排查问题，不同的活给 AI 的材料和要求都不一样。我会告诉它这份东西写给谁看、要什么格式，再加几条限制：要不要引用原文、哪些内容不许编、拿不准的地方要标出来。一开始我只说“帮我总结一下”“帮我写一下”，拿到的都是套话；把背景、读者、格式、重点和限制补上以后，结果好了很多。

第二步，先让 AI 整理信息，先不急着写稿。

我把相关的长文档、会议纪要、表格和历史资料丢给它，让它按几个固定的方面提取信息：背景、目标、现状、问题、结论、风险、下一步。它会给我一份分好类的要点。我先过一遍，看有没有漏掉的材料、有没有理解错的结论，有问题就补资料让它重新提取，要点齐了再往下走。

第三步，按读者分别起草。

要点有了，我再让它按不同场景写初稿。给领导看的，写成一页纸的摘要，先说结论，再说风险和建议；给执行的同事，拆成任务，写清谁负责、什么时间、怎么做；给用户的，写成 FAQ、操作说明或者通知；做复盘的，按背景、过程、结果、问题、经验的顺序写。同样的内容，以前我要自己改好几遍，现在几个版本很快就能出来。

第四步，我自己核对事实。

这一步我从来不会放手。AI 组织语言、理结构确实快，可一到具体的数字、时间、人名、权限、系统名称和政策口径，我一定回原始资料逐条对，不让它凭感觉补。我也会要求它把自己拿不准的地方标成“需确认”，别写得好像很确定。核对完，我再改事实、调措辞、定重点，最后成稿。

第五步，把好用的做法存成模板。

某一类活儿跑顺了，我就把里面效果稳定的提示词、输出结构和检查清单存下来，慢慢攒出了项目周报、会议纪要、问题排查、PRD 审阅、数据分析结论这些模板。下次再遇到同类的活，直接套模板，补上当次的资料就行。

这几步我也尝试调整过。有一阵我把所有要求塞进一条很长的提示词，想让它一次写完，效果反而不如分步做稳定。

有没有效果，我是怎么判断的？

这套做法我在日常工作里一直在用，不是只试了一次。不过我没有每次都掐表计时，下面的对比主要是我自己对同类工作前后的感受。

说用时变短，这里面已经算上了我核对和修改的时间。省下来的主要是找资料、理结构和写第一稿的时间，我把这部分时间花在了核对事实和打磨重点上。前后做的都是要正式交出去的材料，难度和要求差不多，标准没有因为用了 AI 放低。

哪里不好用，我踩过什么坑？

• 问得太笼统。 刚开始我直接说“帮我总结一下”“帮我写一下”，出来的东西很空，质量也时好时坏。它不知道写给谁、要什么格式、重点在哪。后来我每次都写清背景、读者、格式、关注点和限制，结果才稳定下来。
• 太信它给的事实。 它整理文字很在行，可是碰到具体的数字、时间、政策、人员、权限和系统逻辑，有时会编一个听起来合理、实际上不存在的答案。所以这类内容我一律回原文核对，也让它主动把不确定的地方标出来。
• 提示词越写越长。 我曾经以为要求写得越全越好，结果它顾了这头忘了那头。后来改成分步：先提取，再分类，再起草，最后查漏，每一步只让它做一件事。
• 没有检查清单就交稿。 不给它检查项，它很容易漏掉风险、前提条件、依赖关系和还没确认的事。现在我会让它按几项自己再查一遍：依据是什么、哪些待确认、有什么风险、下一步做什么。

流程跑顺了以后，**有些内容我还是坚持自己来：对外发布的、涉及政策和合规的、涉及数据口径的，**都得人看过才能发。AI 可以帮我写，出了问题还是我负责。

如果你也想做类似的事情，可以从哪里开始？

这个方法适合经常要查资料、写材料、跟不同角色打交道的人，比如项目经理、产品、运营，还有经常写总结和汇报的技术同学。前提是资料能交给 AI 看，而且有人愿意对最后的内容负责。

开始前准备三样东西：这次任务的原始资料，越全越好；一段说明，讲清楚写给谁、要什么格式、哪些不能编；一份检查清单，至少包括依据、待确认项、风险和下一步。

第一次可以先拿经常做、出错影响也不大的小活练手，比如会议纪要、文档摘要、FAQ、通知或者改写材料。这类活好验证，也容易让同事看到效果。流程顺了、模板攒起来了，再慢慢用到更复杂的事情上。

对外发布、涉及政策合规、涉及数据口径的内容，一定要人工审核。如果原始资料本身就缺或者互相打架，AI 也帮不上忙，得先回去把信息补齐、对齐。

最后，我想分享给大家的话

用了这么久，我觉得 AI 不能只拿来聊天，要放进具体的工作里，也要讲清楚哪些事归它、哪些事归我。背景、读者、格式、限制给得越清楚，它的东西就越能用。

它帮我省下的，主要是在好几个系统之间翻找、复制、拼凑的时间。核对、拍板、对外发布，这些还是我自己来。

想试的话，可以先从下一次开会的纪要开始，每周都有，写错了也好改。先把这一件做顺，再往别的活上推广。

25 解决方案 Skill：把售前方案周期从 1 周压到 2 小时

先用一段话说清楚，我做成了什么

我日常需要为客户撰写企业培训解决方案（Word / PPT），支撑售前打单。过去采用从零手工编写的方式，主要问题是需求分散、师资课程匹配靠个人经验、一份方案要写一周，不同人产出的质量差异也大。从 2026 年 6 月开始，我尝试用 CodeX + 飞书 CLI 把售前方案流程固化成「解决方案 Skill」。经过 3 个多月、18 个版本的迭代和全团队推广，目前的结果是一份方案初稿 40 分钟～2 小时就能产出，其中仍需人工完成的是确认方案类型与大纲、核对老师档期，以及按客户情况做定制调整。

原来怎么做，为什么值得改变？

这项任务由方案负责人和解决方案专家完成，频率几乎是每周——客户经理拿到客户需求，方案就要跟着出。

原来的流程大致是四步：

1. 收到客户的比选邮件、需求表格，再结合客户经理的口头补充，把需求拼完整。
2. 凭个人经验从师资库、课程库里筛选匹配的老师与课程。
3. 按标准模板从零排版，写成 Word 或 PPT 方案。
4. 人工检查一遍，交给销售或直接发给客户。

最麻烦的是需求理解和匹配：需求分散在邮件、表格、反馈里，字段不统一；师资和课程匹配完全依赖个人经验，移动标包、中标师资这类约束容易漏；PPT 视觉制作尤其耗时。更麻烦的是，不同人写出来的方案结构、专业度差异明显，内部成本、标包信息还容易误写进对外材料。

影响很直接：一份方案从零写大概要一周，客户比选时间紧的时候，方案质量就会打折；如果敏感信息误写进对外材料被客户看到，就是更严重的事故。

我具体怎样把 AI 用进去？

我选一次有代表性的任务来讲：接到某省移动公司的一个培训需求，要在一周内输出一份可参与比选的 PPT 方案。

按发生顺序，整个流程是这样的：

1. 第一步，先准备输入：把客户的比选邮件、需求表格、客户经理的补充信息收集到一起，不需要整理顺序；同时确认师资库、在线课程表和标准 PPT 模板可用。
2. 第二步，交给 AI 解析：让 CodeX 通过飞书 CLI 读取需求资料和资料库，自动抽取客户、培训主题、人群、课时、交付方式等字段，形成结构化需求卡；先判断是普通培训方案还是认证+培训方案。
3. 第三步，AI 匹配资源：从师资库和在线课程表里按主题、行业、人群匹配主推和备选老师、课程，输出推荐理由和风险标识。
4. 第四步，人工确认大纲：AI 先生成 PPT 逐页大纲，我确认章节结构和重点，必要时调整——这一步不确认，不进入正式生成。
5. 第五步，生成初稿：确认后 AI 复制标准模板填充内容，生成方案初稿，保留模板的章节节奏、版式和页码。
6. 第六步，质检与人工核对：AI 跑质检，检查模板完整性、课程链接、敏感字段是否外露；我处理阻断项、核对老师档期，再按客户情况做定制调整，最后交付。

材料一：实际使用的提示词

最开始跑通流程时，我对 CodeX 的要求围绕“解析—匹配—出大纲”三步展开：

读取这份客户需求（比选邮件 / 需求表格），抽取培训主题、目标人群、人数、课时、交付方式，判断方案类型，从师资库和在线课程表里匹配主推与备选老师和课程，生成 PPT 逐页大纲供确认。

固化进 Skill 后，输入大幅简化——把客户资料丢进去，工具按 SOP 自动完成解析、匹配、出大纲、生成初稿，我只需要在各个确认节点把关。

材料二：一次方案任务的五要素拆解

材料三：人工与 AI 分工流程图

有没有效果，我是怎么判断的？

这不是一次性尝试：从 6 月跑通流程、写完 MRD、2 个 Skill 和 4 篇 SOP 文档，到 8 月前完成 18 个版本迭代，我自己持续用了 3 个多月；后续 19～21 版由产研团队完成工程化与产品化，正式上线为团队级工具。

再补两个判断依据：一是公司 8 月底的信息流通站立会把它列为“企业版解决方案 Skill 优秀实践”，我获评优秀实践奖；二是有真实项目验证，同事用 Skill 辅助完成某金融科技项目的 3 份标书，4 天完成原本需 10 天的工作量，项目顺利中标 42 万。

还需要说明的是：40 分钟～2 小时是产出方案初稿的时间，包含大纲确认与人工核对环节。

哪里不好用，我踩过什么坑？

写几个真实的问题：

1. PPT 生成与拆分：早期直接生成图片型 PPT，无法继续编辑，拆分耗时过长、token 消耗大。后来并行走“固定模板填空、生图转可编辑、HTML 导出”多条路径，必要时以图片输出、人工介入。
2. Word 模板被破坏：AI 按章节填充时偶尔会把模板内容删掉，生成结果和原模板样式差异大。后来改成占位符替换，AI 只识别占位符，精准度明显提高。
3. 资料格式不统一：客户邮件、需求表、反馈格式五花八门，第一版先做标准化输入，先把高频、规范的场景跑通。
4. 敏感信息风险：内部成本、标包、费用字段容易误写入对外方案，需要质检阻断；师资库明文存储也有信息安全担忧。
5. 算力与网络限制：图片转可编辑 PPT 耗时久、算力额度不足、网络访问受限，是目前仍在迭代的待优化项。
6. 人工核对不可少：AI 输出的版本仍需要人工核对一遍，全流程不能完全放手——这也决定了它的定位是“助理”，而不是“替代”。

如果你也想做类似的事情，可以从哪里开始？

这个方法适合有重复性方案、文档生产需求的人（售前、解决方案、教研、运营都适用），在能用 CodeX / Claude Code + 飞书 CLI 的条件下使用。

开始前需要准备：搭好工具链，把自己最常做的那类工作 SOP 化——先做什么、再做什么、产出什么，再备好标准模板和资料库。

第一次尝试，建议先拿自己最常做的一个重复任务练手，比如某类方案或周报，先让它输出大纲、人工确认后再生成。遇到图片转可编辑 PPT、模板保真、敏感信息校验这类情况时，需要人工介入，或者作为下一轮迭代的优化点。

最后，想分享给大家的话

高频、规则明确、多人共用的重复劳动场景，是最适合做成 Skill 的。我做这件事最大的感受是：个人经验沉淀成团队能力，比“省自己一点时间”更有价值——从 6 月我一个人的工具，到 8 月成为销售和解决方案团队的通用工具，中间就是一次次迭代和一次深度体验评审。如果你也有一件天天重复、又有点规则的事，值得试一次。

26 打印模板生成：从半小时手工绘制，到 2 分钟 AI 自动复刻

先用一段话说清楚，我做成了什么

我们公司是 ERP SaaS 厂商，客服人员日常需要帮忙客户生成复杂的打印模板。常常是客户发过来一张随手拍的打印件的照片，说我想要这样打印，但模板太复杂了，帮我生成一个。过去手工在打印管理器中创建，绘制表格，调整行距、字体，还要关联字段。复杂的模板，半小时起步。随着 AI 技术能力越来越强大，我们尝试用 AI 技术实现从图片自动生成打印模板，关联数据字段。图片自动生成打印模板耗时 2 分钟左右。

原来怎么做，为什么值得改变？

从历史工作记录来看，每个季度，我们客户人员大概会接到两百多个帮客户生成打印模板的需求，以每张打印模板耗时 30 分钟算，也得上百小时，复刻不准确来回沟通修正更费心费时。

我具体怎样把 AI 用进去？

客服提供的照片，常常是随手一拍或直接屏幕截图。图片的背景复杂，表格也以各种角度呈现，也可能是别家的模板，带着各种置灰的模板提示。

所以，第一步，我们先调用视觉模型，对图片进行归整，提示词：

图片是一个报表的打印件，请去掉背景，并将图片旋转为正确的角度，并清晰化。

处理后，第二步，先用二维码 / 条码 OCR 识别图片中是否有二维码 / 条码，并识别出所在位置和具体格式。再用多模态模型识别出图片中是否存在商标 / 嵌入图片，并识别出所在位置，用于后续整合。

第三步，调用表格 OCR，识别表格内容及格式信息，再用我们自有的打印模板格式知识文档，结合 OCR 返回的 json 格式，生成自有打印模板 json 格式。这一步出现的问题是 OCR 并不会识别出文字的字号，因此需要根据字块的长宽等信息进行等比缩放，对应到合理的字号。

第四步，将二维码、嵌入图片等信息整合到自有模板中。

最后一步，将识别出的列和系统提供的数据源都提供给大模型，让其自动匹配。整个流程，用工作流串联，也方便各级调优。

示例如下：

（1）客户提供的原始图片

（2）生成的打印模板

有没有效果，我是怎么判断的？

上线后，Q3 季度，除拷贝类模板外，打印模板生成已完全被 AI 打印模板生成接管。

哪里不好用，我踩过什么坑？

目前待优化的问题是，有少部分字段无法从中文列名和字段值，直接对应到我们系统中的数据源，需要手工配置。后期准备建立一个常见别名的知识库，提升匹配度。

如果你也想做类似的事情，可以从哪里开始？

早期想让大模型一次性完成所有的功能，结果发现模型在识别表格上能力还是欠缺，经过多次尝试后，选用不同的模型组合完成，效果就比较理想。多种模型结合，再落地为工作流的方式比较容易落地，且效果更优。

27 把写作的「周边活」交给 AI：一个架构师的自媒体全流程流水线

先用一段话说清楚，我做成了什么

我是年轮，一名架构师，业余时间在公众号和视频平台做自媒体。写作本身已经很耗时，但真正拖住我的是它周围一圈重复劳动——想选题、找资料、排版、配图、登记、统计数据，每项都不难，加起来却能把一篇文章拖成好几天。从 2026 年 7 月起，我用 AI Agent、定时任务和本地知识库，把从选题到复盘的全流程串成一条流水线。两个多月跑下来，「周边活」基本自动化：每天早上自动出选题晨报；我口述观点、挑好对标选题后，AI 按我的写作风格出初稿，再接着完成标题、配图、发布和数据采集；复盘有固定窗口和模板，结论自动回流到下一篇。人需要做的只剩：给出观点、核对事实、裁决风格。

原来怎么做，为什么值得改变？

这个号是我一个人在做，没有团队和助理，做内容的时间只能从晚上和周末里挤。原来的流程：灵感记进备忘录 → 周末拼提纲 → 写正文、找配图、手动排版 → 粘贴发布 → 有空看一眼阅读数。

最麻烦的是三步。选题：灵感不成体系，动笔时反而不知道写哪个。写作：写一篇文章也要好几天，配图要找、排版要手调，发布后还要把链接和数据一条条登记——每项十几分钟，却每次都一样，必须有人干。反馈：发布后没有系统复盘，好坏全凭印象。

还有一个起步前绕不开的痛点：历史文档和素材的整理。 写内容要用手头的旧素材，可我的旧文章、收藏、聊天截图、对标样本散落在好几个地方，找东西全靠翻，翻不到就重写一份。真做起来才发现，整理比写新文章还费时间；而不整理，所谓的「素材库」就只是个堆放处。后来我让 AI 把历史文章和素材集中过了一遍：归类、去重、打标签，能直接复用的挑出来单独放。整理完之后，「找得到」才第一次成为常态。

我是如何用 AI 完成任务的？

核心思路一句话：让 AI 替我「跑流水线」——把一篇内容从想法到复盘拆成固定阶段，每阶段有固定输入、产物和检查点；阶段内交给 AI，阶段之间的判断留给我。每个阶段的产物都落成文件（正文、标题记录、审核报告、数据快照……），流程靠文件接力，不靠记忆；我需要做的只是确认，然后说「继续」。

（一）每个环节，AI 做什么、我做什么

• 选题：每天早晨自动生成「晨报」：昨日数据、今日待办、3～5 条低粉爆款样本；我负责挑。
• 素材：灵感、资料统一进「选题池」；外部素材批量入库（一位创作者 620 条作品文字稿）。

写作：我给立场（对谁说、说什么的判断），AI 读我的定位、风格规则和写作资产后出初稿。

• 审核：AI 联网核对事实与引用，标出敏感表达；我决定改不改。

排版与发布：AI 生成可直接粘贴的排版版本和按固定规则生成的封面；我扫码发布。

• 登记与数据：AI 核对后台状态并登记，定时任务按 T+3/T+7 窗口自动采集快照。
• 复盘：数据齐了自动进队列，AI 出复盘初稿，结论回流到写作资产和选题池。

（二）价值不在单个 Skill，而在编排

先澄清一个容易误解的地方：这套东西的价值不在「会用很多 Skill」。 单个 Skill 只是某一步的说明书——写个初稿、起个标题，单独看都很普通。真正起作用的是编排：把这些 Skill 按顺序接成一条流水线，规定谁在什么时候触发、上一步交什么文件给下一步、哪一步必须停下来等我确认、失败了怎么兜底、产出的结论怎么回流。系统化 = 触发 + 交接 + 检查点 + 状态 + 闭环，缺一样，它就退化成「零散地用 AI 干活」。

这条流水线不是一个大提示词，而是拆成十几个自定义 Skill（可以理解为可复用的技能包）：写作、起标题、审核、排版、发布、数据采集、复盘各一个，往外还有配图、贴图、短视频、素材整理。每个 Skill 只负责一步，写清楚这一步的输入、约束和产物；再由一个全局 Skill 负责调配：按顺序触发，把上一步的文件交给下一步，在需要我拍板的地方停下来。任务状态也存在文件里，所以隔天回来只要说一句「继续」，它就知道现在该干什么。

（三）流水线背后沉淀了什么

沉淀下来的知识分四类：一是写作规则——从自己过往的文章里萃取的文案规律、标题公式、选题类型，加上开篇模板、文章框架、结尾引导，以及每次改稿后追加的风格条目；二是素材——每天抓的低粉爆款样本、平时随手存的灵感、对标账号的好文章；三是运行记录——每篇内容从项目卡、审核报告到数据快照、复盘结论的全套过程文件；四是身份与边界——定位、内容价值观、禁区与偏好。AI 每次动笔前先读这些，保证「像我」和「不越线」。

（四）文件放在哪

文件组织很朴素：一个纯文件夹的本地知识库，自媒体单独一个目录，里面按用途分成八块——我的信息（定位、风格、禁区）、选题（选题池、起号计划）、内容管理（每篇内容的项目文件夹）、发布与复盘（内容总表、月度复盘）、自动化（采集配置、待复盘队列、任务日志）、写作资产（开篇模板、文章框架、标题公式、爆款样本）、模板（项目卡、审核报告、数据快照等 12 个）、原文素材。每篇内容一个项目文件夹，命名「日期-标题」，里面随流程逐步出现项目卡、正文、标题记录、审核报告、排版记录、发布记录、数据快照和复盘；全局只有两张总表：任务总表和内容总表。AI 每次只读当前步骤要用的几个文件，省上下文，也不容易串。

有没有效果，我是怎么判断的？

先说清性质：这不是一次尝试，而是持续运行至今的机制；比较对象是我自己前后发布的内容，难度和质量要求一致。

其一是反馈闭环：以前偶尔看一眼后台，现在每天自动采集（已运行 40 多天），每篇按 T+3、T+7 采数；中途失败过，但口径不丢——窗口不设上界，恢复后自动补采。

其二是复盘真的改变了写作，已完成 2 篇：工具实测文转发率 7.1%，创下账号最高纪录，确认「实测文是传播位」；热点观点文阅读接近 3000，验证「热点 + 第一人称利益」。一个反直觉发现：一篇内容 T+14 判断「长尾停滞」，T+31 复采阅读从 543 涨到 1003，直接改变了观察数据的窗口设定。

其三：我没有严格计时，但周边活基本不再占用时间，我集中投入的是给观点、核事实、做取舍；时间节省里已包含检查与返工。

哪里不好用，我踩过什么坑？

第一个坑：AI 写得「太正确」，但没有观点。 我最初想让 AI 全自动产出，结果初稿完整通顺，读完却记不住任何东西——它没有立场。后来把分工倒过来：观点、取舍由我给，AI 负责展开、核实、排版、登记。想通这点，流水线才真正跑顺。

第二个坑：AI 刚开始写的文章，不像自己。 AI 的初稿语法正确、结构完整，但语气、句式、开合方式都是「通用写作」的味道，读起来不像我。解法不是每次手动改，而是把风格写成文件：从自己的历史文章里提炼开篇模板、文章框架、结尾方式，再列一份「避免清单」（比如「在这个快速变化的时代」「废话不多说」这类句子一律不许出现），每次改稿的反馈也追加成条目。规则改了几轮之后，初稿才慢慢接近「我自己写的」。

第三个坑：整条流水线的编排，是慢慢调出来的。 一开始我想一步到位，结果每一步的输入输出对不上：写作拿不到选题池的最新数据，排版找不到刚改完的正文，定时任务不知道该采哪一篇。后来才定下「固定阶段 + 产物文件 + 检查点」的结构，用项目卡记录状态，靠文件接力；每个环节的提示词、时间窗口和失败兜底也各改了好几版。流水线不是设计出来的，是跑出来的。

仍需人工的环节：观点的最终表达、事实核对、风格采纳、发布，以及回复读者。

如果你也想做类似的事情，可以从哪里开始？

适合像我一样「有稳定输出需求、但被繁琐的活卡住」的人：内容创作者、独立开发者、做个人品牌的职场人。前提是已有持续更新的账号和一批历史内容（风格规则要从自己的内容里提炼），并接受「先手动跑通几遍再自动化」。

搭建思路是：先和 AI 沟通，设计一个适合你的文件结构，包括之前说的个人信息、灵感、风格规则、写作资产（开篇模板、文章框架、标题公式、爆款样本）、存储文章的项目文件夹等；然后参考并设计每个步骤的 Skill，最后用一个总控 Skill 把整个流程串联起来。

最后，我想分享给大家的话

搭这条流水线之前，我以为在解决「写得慢」；搭完才发现，真正解决的是「启动难」和「没反馈」——写作不是瓶颈，瓶颈是它周围那圈没人愿意干、又必须有人干的活。

我把重复的交给 AI，把判断留给自己。跑起来之后，一件事更清楚了：内容真正值钱的部分是「对谁说什么」——AI 替不了，也不该替。

28 用 AI + Python 批量制作 CoA，把重复填表变成一键生成

我做成了什么

我在一家医药行业第三方检测公司工作，实验室每天都需要给客户出具 CoA（Certificate of Analysis，分析证书）。过去，我们要把实验室检测数据逐项填进 Word 模板。不同客户的模板字段和格式要求不一样，手动填写不仅耗时，还容易抄错数据、改乱排版。

从 2026 年 9 月开始，我尝试用 Trae AI 辅助编写 Python 脚本，将 Excel 中的检测结果批量填入对应的 Word 模板，再封装成同事可以直接运行的小程序。目前，单份 CoA 的生成时间约为 1 分钟，已生成并核对的报告没有发现格式错误。分析日期等数据源字段的更新，以及最终数据核对，仍然由人工完成。

原来怎么做，最麻烦的是哪一步

原来的流程分成四步：

1. 实验室出具检测数据。
2. 打开对应客户的 Word 模板。
3. 手动填写样品信息和检测结果。
4. 核对数据与格式。

最麻烦的是第三步。数据已经在 Excel 里，但交付给客户的文件需要使用指定的 Word 模板，我们只能对照两份文件逐项填写。

不同客户的模板又不完全一样，有的字段名称不同，有的对单位、小数位数和排版有具体要求。每做一份报告，都要重复填写、检查和调整格式。原来每份大约需要 20～30 分钟，报告多的时候，同样的操作要反复做很多遍。

我希望解决的，就是这部分规则明确、却需要大量手工重复的工作。

具体怎样把 AI 用进去

我在 Trae 里使用 AI 辅助完成，主要分成三步。

第一步：准备输入资料，把要求说清楚

我准备了三份文件：

• 客户使用的 CoA Word 模板。
• 实验室检测结果 Excel。
• 自己整理的需求说明。

把这三份文件放进 Trae 工作区后，再给 AI 写提示词，让它根据模板和数据编写 Python 脚本。

模板告诉 AI 最终文档应该是什么样，Excel 提供需要填入的数据，需求说明则交代字段怎样对应、哪些格式必须保留。

这里不能只说一句“帮我把 Excel 填进 Word”。比如 Logo 的位置、单位的写法、小数保留几位，都需要在需求里说明。把这些细节提前交代清楚，后面才能少花时间反复调整。

第二步：调试脚本，核对生成结果

AI 写出代码后，再围绕实际生成的 CoA 调试。

这一环节重点看两件事：一是数据有没有填对，二是模板格式有没有保留。样品信息、检测结果、单位和日期需要对应正确，生成后的文档也要符合客户的格式要求。

字段映射是其中的重要部分。Excel 中的数据需要填进模板的哪个位置，要有明确的对应关系；后续模板或列名变化时，也需要相应调整映射表。

这次脚本编写和调试大约花了 60 分钟。相比每份报告都手工填写，这部分投入可以在后续重复使用中摊薄。

第三步：封装成小程序，分享给同事

核心流程跑通后，再把脚本封装成小程序。这样，同事不需要每次进入 Trae 与 AI 对话，直接运行程序就能生成报告。

对我来说，关键不只是 AI 帮忙写出了代码，而是这些代码我能看懂、能修改。需要调整字段或适配模板时，可以继续改，不必每次都从头做一遍。

最终的分工也比较清楚：AI 辅助开发和调试，Python 程序负责重复填充，人负责更新数据源、维护映射和核对结果。

效果怎么样

这次记录中，脚本编写和调试约 60 分钟，一次生成及核对约 5 分钟，两项合计约 65 分钟。后续复用脚本时，单份生成约需 1 分钟，但这个时间不等于包含数据准备和最终核对的全部耗时。

最核心的节省，是不用反复手工填数据、改格式。程序减少了逐项抄写的机会，也让同一套模板可以重复使用。不过，源数据和字段映射仍然需要确认，不能因为文档生成得快，就取消最后的核对。

如果你也想做类似的事情，可以从哪里开始？

这类方法适合有固定格式模板、需要批量填充数据的人。例如 QA、采购、外贸、行政等岗位，都可能遇到批量质检报告、报价单或其他类似文档。

不一定要先学会 Python，但需要能把要求说明白，也需要能判断生成结果是否正确。

开始前，建议准备好三样东西：

• 一个稳定的模板。 尽量把占位符标准化，例如使用 {样品名称}、{分析日期}。
• 一个标准化的数据源。 Excel 列名与模板字段尽量一致，不一致的地方明确写出映射关系。
• 一套约定好的处理规则。 提前和相关同事确认空值、异常值应该怎样处理，避免让 AI 或程序自行猜测。

第一次练手，可以只拿一份最简单的模板和一份数据源，先让 AI 写基础脚本，跑通“从 Excel 填入 Word”的核心逻辑。确认结果正确后，再考虑批量处理和封装，不必一开始就加上打包、归档等功能。

如果数据源是扫描件、手写记录，模板包含复杂艺术字或特殊图表，或者数据有大量缺失值、需要人工判断填什么，就仍然需要人介入处理。

我最想分享的一点是：给 AI 写需求时，不要怕具体。Logo 放在哪里、单位怎样写、小数保留几位，这些看似细小的要求，往往决定了生成结果能不能直接使用。把要求说清楚，再用实际结果核对，才能把一次脚本尝试变成同事也愿意用的工具。

29 从人工排查到 Agent 自动化会话生命周期管理

案例名称

ChatAgent 用户会话全生命周期管理 Agent：会话记忆分类存储、异常自动发现与修复、自动归档。

案例简介

我主要把 AI 用在 ChatAgent 的用户会话全生命周期管理上。之前系统经常出现会话中断、状态错乱、记忆堆积过期这些问题，一出问题就要开发运维手动去 Redis、数据库查数据，人工修正会话状态，排查修复慢、容易人为误操作，而且很多隐藏异常要等用户反馈才知道。

于是我引入了 Agent 编排做会话流程自动化：会话拆成短期状态、工作记忆、长期记忆分开存储，借助 checkpoint 实现会话可恢复；事件 + 定时轮询自动扫描识别异常，Graph 编排处理节点，普通异常自动修复，高风险问题走人工介入生成工单；重逻辑放 MQ 异步执行，每步操作留完整 Trace。

之前的老方案是什么，存在什么问题

没使用 AI 之前，会话正常流转靠硬编码的状态机，一旦遇到网络抖动、消息丢失就容易卡住。异常会话全靠用户上报，我们再去多套存储里定位问题，手动修复状态、清理过期数据。归档清理只是简单跑定时脚本，不会智能识别脏会话。整个过程重复繁琐，还存在误改数据的风险。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

解决方案如下：

1. 记忆分层存储：将会话拆分成短期状态、工作记忆、长期记忆分开存储管理，借助 checkpoint 实现会话可恢复。
2. 自动发现异常：采用事件 + 定时轮询的方式，让 Agent 自动扫描识别各类会话异常，不再等用户反馈。
3. Graph 编排处理：通过 Graph 编排不同处理节点——普通可恢复的异常调用工具自动完成状态回滚、清理无效记忆、会话归档；遇到高风险、没法自动处理的问题，走人工介入流程生成工单。
4. 异步与可观测：把修复、归档这些重逻辑放到 MQ 异步执行，不占用用户请求链路；每一步操作留下完整 Trace 记录，方便后续复盘排查。

过程中踩过的坑：

• 一开始没有限制 Agent 执行轮次，损坏的会话会造成 Agent 无限循环消耗资源；
• 出现过把高风险操作直接交给 Agent 执行，差点误删有效记忆；
• 犯过把重处理逻辑放在同步接口，拖慢用户请求的错误。

经验：Agent 自动化要有明确边界，设置最大轮次防止死循环；修改、删除会话和记忆这类高危操作，一定要保留人工确认通道；重业务逻辑走异步消息队列，不阻塞主链路；做好消息幂等处理，完整留存 Trace 日志；底层核心状态规则不能完全交给大模型自由决策。

与旧办法相比，新办法的结果如何（数据对比）

• 大部分会话异常可以被提前自动发现，不用等用户来反馈；
• 可以自动修复的故障处理速度提升很多，只有少部分高风险情况才需要人工介入；
• 研发运维处理会话故障的工作量下降，减少了人为修改数据带来的失误；
• 会话相关的记忆幻觉问题有所缓解，整套会话的可观测性变好。

通过这个 AI 落地案例，我的收获有哪些

1. 给 Agent 划定边界是第一步：最大执行轮次、高危操作人工确认通道、核心状态规则不交给模型自由决策——自动化越强，边界和护栏越要明确。
2. 异步 + 可观测是生产级 Agent 的基本功：重逻辑走 MQ 不阻塞主链路，消息幂等、Trace 全留痕，出了问题才能复盘，用户链路才不会被打扰。
3. 让 AI 先于用户发现异常：从“等用户反馈再修”到“系统自动扫描识别”，是运维从被动到主动的关键转变，也是这套方案最核心的价值。

30 财务人用 AI 做工具，踩过三个坑后总结出的原则：换个模型，别跟 AI 死磕

案例名称

财务人用 AI 做工具，踩过三个坑后总结出的原则：换个模型，别跟 AI 死磕。

案例简介

我们是一家小公司。每个月末那几天，要按规定格式集中处理当月收集的各种报销凭证，工作内容机械重复。我就想：能不能用 AI 省点时间，提高效率？

之前的老方案是什么，存在什么问题

之前要把当月收集的报销凭证（主要是电子发票、火车票等）按时间顺序排好，放进一个 Word 文档，同时把发票里的信息——发票类型、发票号码、开票日期、项目名称、金额等——汇总到 Excel 里，再交给会计做账。最耗时的就是把发票内容一条条录进 Excel，全靠人工，所以每到月底就特别忙。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

我的工作内容有一部分是每个月都要人工录入发票和火车票，枯燥又容易出错。我一直想做个小工具：上传票据图片，自动识别内容，汇总到一张 Excel 表里。以前觉得这得找专业的人开发，现在我决定通过 AI 来完成，顺便看看 AI 编程到底能做到什么程度。

我的做法是分三步走：先跑通流程，再解决效果，最后补齐功能。 之所以这样安排，是因为我判断“能不能跑通”和“跑得好不好”是两类问题，混在一起处理容易顾此失彼。之前，我也了解到 AI 比较适合一个个解决问题，把问题细分后 AI 实现的效果会更好。

第一步：跑通流程。

我先从发票文件入手，不给 AI 提太多要求，只说“帮我生成一个网页，识别上传的发票文件，写到一个 Excel 中”。AI 反过来问我识别方式和字段需求，我选了本地 OCR，并列出要识别的发票字段：发票类型、发票日期、开票号码、项目名称、金额、税额、价税合计。

很快它给出了一个可以上传文件的网页。我传了一张发票，直接报错。我把错误信息原样贴回去，它修好一个，又冒出另一个报错；这样循环几轮之后，我发现居然绕回了第一个报错——等于在原地打转。

这时候我觉得 AI 有点不靠谱，问了朋友又查了些资料，怀疑是不是模型本身能力不够。听说 GLM 表现不错，就手动切换到 GLM 模型继续迭代。换模型后，几轮下来终于把报错都解决了。从上传文件到识别出内容，最初的流程终于跑通。

这一步的教训是：遇到反复修不好的问题，别急着怀疑自己的描述方式，先怀疑工具本身。

第二步：解决识别效果。

流程通了，但本地模型识别出来的内容基本都有问题，没法用。我直接问 AI 怎么办，它推荐改用云服务。想到公司之前用过阿里云，我就让它去接入阿里云 OCR。

接入后照样有报错，继续贴错误、迭代几轮，文件内容能识别出来了——但准确度还是不够，有些列识别得不对。

我怀疑是 AI 选的对接模型不对，于是自己去阿里云文档里找到了专门针对发票识别的 OCR 模型，把文档网页地址直接发给它，让它照着文档对接。这次迭代几轮就成功了，识别准确度达到了可用的水平。

这一步我学到的很重要的一点是：AI 自己找资料不一定靠谱，当你比它更清楚该用什么时，把准确的资料喂给它，比让它瞎猜效率高得多。

第三步：补齐功能。

有了发票识别的完整经验，加火车票就顺畅多了。我照葫芦画瓢，直接找到火车票识别模型的文档给 AI，几轮迭代就完成了。

之后又加了一个功能：把发票、火车票文件按编好的顺序插入 Word 文档，方便会计记账人员直接使用。

回顾整个过程，我的角色其实更像一个“产品经理加测试员”：负责拆解需求、准备资料、拿真实数据验证，遇到问题把现象准确地反馈给 AI。AI 负责写代码，而判断“这个结果能不能用”“问题出在哪一层”，始终需要人来把关。

用过这几轮之后，我最大的感受是：AI 编程没有想象中神奇，但也没有想象中遥远，关键是你得会安排它。

与旧办法相比，新办法的结果如何

连续使用两个月后，我估计能少花一天左右的时间。

• 以前全手工：整理票据、一张张看、录进 Excel、最后再回头核一遍，一天下来基本干不了别的，前后加起来两天左右才能收尾。
• 用了工具之后，票据攒齐了往工具里一传，让它自己跑，我这边主要做两件事：一是前期把文件收拢、命名理好，二是跑完之后检查结果。整个流程半天不到就能完成。个别票据还是会识别错，金额、日期这种关键字段我每次都会重点扫一遍，看到不对就手动改一下，量不大。

成本这边也变了：以前主要靠人力，现在人力花在收文件和检查结果上，但多了云服务的调用费用——根据每月识别量浮动，不算多。整体算下来是划算的。这个时间是我的粗估，没有精确计时——省下的时间主要来自不用再一条条往里敲了。

通过这个 AI 落地案例，我的收获有哪些

在第一步中，遇到报错，我的做法一开始很粗暴：报错信息一贴，等它改，改完再传一次，再报错就再贴。开始我还觉得挺正常，毕竟写代码哪有不报错的。但改到后面就感觉不对——每次它都信誓旦旦说“问题找到了”，确实也修好了这个错，可紧接着又冒出个新的。 我当时还安慰自己，说这是在逐步收敛，问题一个个在变少。结果几轮下来，我又回到了最开始那个报错上，绕了一圈，原地踏步。

这时候我才明白：可能 AI 压根没找到问题根因，或者最初的实现本身就有问题，后面怎么改都不对。换了个模型，问题才真正解决。

所以我现在的原则是：报错信息可以直接粘贴，但同一个问题如果修了三四轮还在换着花样出现，就别再喂了；另外，遇到复杂问题一开始就用好模型，能省很多时间。

现阶段只是做了一个简单的工具，只覆盖了日常工作中常用的发票和火车票两类，其他票据遇到还得手工处理，比如纸质出租车票、定额发票等。目前这些暂时靠人工兜底，后续再考虑如何实现。

最后，我想分享给大家的话

案例中的这个方法也适合刚开始用 AI、想拿它提升日常工作效率的人。前提是处理的信息不太敏感。开始前也要准备一些测试用例。

第一次尝试，建议先挑日常流程固定、重复度高的小任务来练。遇到特殊情况需要人工介入时，就先别硬套。

最后，我想给同样想动手的人一点建议：有想法就先动手试试。可以先给自己定一个日常工作里的小改善目标，然后把它拆成“核心流程先跑通、再提高准确率、最后再扩充功能”三步，一步步推进。遇到问题别急，静下心来慢慢解决。

31 从人工分析到 AI 辅助威胁狩猎：让网络安全检测效率提升约 10 倍

从一项重复性工作开始，让 AI 参与网络安全检测

我是一名企业网络安全工程师，日常工作之一是开展威胁狩猎（Threat Hunting），主动寻找企业内部可能存在的网络攻击、恶意行为和数据安全风险。过去，这项工作主要依赖人工完成：从公开渠道收集最新网络攻击情报，阅读技术报告，提取攻击者使用的技术手段，再结合企业内部的安全日志编写检测规则，执行查询并分析结果。这一流程不仅耗时，而且高度依赖工程师的专业知识和实践经验。面对每天不断更新的网络安全情报，有限的人力很难对所有值得关注的攻击技术进行及时验证。为解决这一问题，我开始尝试将 AI 引入日常威胁狩猎工作，通过定时任务、结构化提示词、专业知识库、AI Skill 和安全平台 API，将原本分散的人工操作整合为一套相对完整的自动化工作流程。经过持续使用和优化，目前在工作时间内，威胁情报处理和检测任务的完成效率估计提升了约 10 倍。AI 可以承担大量信息整理、初步分析、规则生成及检测结果辅助分析工作，而最终的风险判断、误报确认和安全事件处置仍由工程师负责。

原来的工作方式：大量时间花在重复的信息处理上

网络安全是一场持续变化的攻防对抗。每天都有新的漏洞、攻击工具和攻击手法被公开。对于企业安全团队而言，及时了解这些变化，并判断企业内部是否存在相关风险，是一项长期而重要的工作。

以一次常见的威胁狩猎任务为例：

假设安全研究人员公开了一份最新的勒索软件攻击分析报告，详细介绍攻击者如何获取系统权限、窃取凭据、横向移动，以及最终实施数据加密。传统情况下，我需要先从 RSS 订阅或开源情报平台发现这份报告，完整阅读技术内容，再从中识别值得关注的攻击行为。接下来，需要将这些攻击行为转化为企业安全平台能够理解的检测规则。例如，报告提到攻击者可能通过异常的 PowerShell 命令执行恶意程序，我就需要结合相关技术特征、企业内部日志字段以及查询语法，手动编写检测规则。规则写完后，还需要反复测试，检查是否存在语法错误、字段不匹配或大量误报等问题，最后才能真正用于内部安全检测。

这个过程最耗时的地方，往往不是单纯阅读报告，而是将外部情报转化为能够在企业真实环境中运行的检测逻辑。因为每一份情报涉及的攻击技术不同，企业内部的数据结构也不同，检测规则无法简单复制粘贴。这意味着，即使每天能够阅读大量安全报告，最终能够完成验证的攻击技术数量仍然有限。如果长期依赖纯人工方式，一些新出现的攻击手法就可能无法被及时纳入检测范围。

把 AI 融进工作流：建立从情报到检测结果的完整工作流程

我的思路不是让 AI 简单地帮忙总结文章，而是让它参与整个威胁狩猎流程。

整个流程可以概括为：自动收集威胁情报 → AI 提取攻击技术 → AI 生成检测规则 → 自动执行检测 → AI 辅助分析结果 → 人工最终研判。

第一步：让 AI 定时收集并整理最新威胁情报

首先，我通过 AI 定时任务，指定需要关注的公开网络安全研究网站、威胁情报平台及技术博客，让 AI 按照预设的频率收集最新发布的攻击分析报告。

过去需要人工逐个打开网站、筛选文章，现在我可以让 AI 先完成初步信息收集和整理。但我并不希望 AI 只给出一份文章摘要，而是要求它按照固定框架提取真正有助于安全检测的信息，例如：

• 攻击组织或恶意软件名称；
• 攻击者使用的关键技术和行为；
• 对应的 MITRE ATT&CK 攻击技术分类；
• 可以在终端或系统日志中观察到的行为特征；
• 值得进一步验证的检测方向。

这样做的价值在于把原本篇幅较长、结构各异的技术报告，转换成格式相对统一、能够直接进入下一阶段的分析材料。

第二步：让 AI 学会将攻击情报转化为检测逻辑

这是整个实践中最重要、也是技术难度最高的一步。AI 虽然具备一定的网络安全知识，但它并不了解每家企业具体使用的安全产品、日志字段和查询语言限制。如果直接要求 AI“根据这份报告生成检测规则”，它可能生成看起来非常专业、实际上却无法运行的代码。为解决这一问题，我首先整理了自己过去积累的检测规则、技术文档和实践经验，将常用的数据字段、查询语法、检测逻辑和典型错误整理成 AI 可以参考的知识材料。随后，我将这些知识进一步封装为 AI Skill（可复用的专业任务指令与知识规范）。你可以将 Skill 理解为一份专门写给 AI 的工作手册，它不仅告诉 AI 应该做什么，还明确规定应该怎样做、哪些方法不能使用，以及生成结果必须满足什么条件。通过增加约束，AI 生成的内容逐步从通用的技术建议，转变为更符合实际工作需求的检测规则。

第三步：通过 API 将 AI 生成的规则用于实际检测

完成规则生成后，下一步是让它真正发挥作用。

我通过企业安全检测平台提供的 API 接口，将 AI 生成的查询规则提交至安全平台执行，并获取检测结果。例如，当 AI 从一份攻击报告中识别出“攻击者通过系统命令删除备份，以阻止数据恢复”的技术时，就可以进一步生成针对相关系统行为的检测规则。规则经过必要的语法与安全检查后，可以通过 API 在授权的数据范围内执行，查询企业终端是否出现过类似行为。相比传统方式，这减少了工程师在多个工具之间反复复制规则、提交查询和整理结果的操作。不过，自动执行并不意味着完全放弃控制。对于无法通过校验、涉及高资源消耗或检测逻辑不明确的规则，仍需要人工检查和调整。

第四步：让 AI 辅助分析检测结果

检测规则能够成功运行，只代表完成了技术验证，并不意味着发现了真正的攻击。例如，一条规则可能检测到某台电脑执行了删除系统备份的命令。但这一行为既可能与勒索软件有关，也可能来自正常的系统维护。因此，我进一步尝试让 AI 对检测结果进行初步分析。AI 可以结合进程名称、执行命令、父子进程关系、执行时间及其他可用的上下文信息，对检测结果进行整理，并指出需要重点关注的异常。同时，AI 可以给出初步判断和判断依据，帮助工程师快速定位值得进一步调查的记录。但 AI 的分析结论不能直接等同于最终安全结论。对于潜在的真实威胁、缺乏上下文的异常行为，以及可能影响业务的安全事件，仍然需要人工复核。通过这种分工，AI 主要负责大规模信息处理和初步筛选，工程师则负责复杂场景分析、业务背景核实及最终风险判断。

从单点突破到全链路提速：AI 的真实战果

在实际使用过程中，我观察到的最大变化并不是 AI 在某一个环节比人工快多少，而是多个原本相互独立的工作步骤可以连续完成。

从个人实际工作体验来看，在相近工作时间内，能够处理的威胁情报和完成的检测任务数量，相比过去纯人工方式估计提升了约 10 倍。需要说明的是，这一数字主要来自日常工作量的经验比较，目前尚未通过严格的对照实验进行量化验证。

此外，效率提升也不意味着安全检测准确率同步提升 10 倍。规则能否准确发现威胁、是否存在误报，以及是否覆盖真实攻击行为，仍需要通过后续测试和实际运行结果验证。

现阶段最明显的收益是减少了重复性信息处理和规则初稿编写的时间，使工程师能够把更多精力投入高价值的安全分析工作。

别高估 AI：会写代码 ≠ 会写检测规则

在整个实践过程中，我遇到的最大问题是 AI 对专业检测语言和实际检测场景的理解不够稳定。

问题一：生成的规则存在语法或字段错误。 有时 AI 会使用当前安全平台不支持的字段或函数，导致生成的规则无法执行。这类错误往往并不明显，因为生成的代码看起来结构完整、逻辑合理，但实际提交后才会发现问题。对此，我逐步将平台支持的语法、字段说明和常见错误补充到 Skill 中，并通过实际执行结果持续修正规则生成要求。

问题二：检测规则过于简单或过于复杂。 如果规则过于简单，可能只检测某个文件名或特定字符串，容易遗漏攻击者稍作修改后的行为。如果规则过于复杂，又可能增加查询成本，甚至因为条件设置不合理而产生大量误报。

我发现解决这一问题不能只依赖一句“请优化检测规则”，更有效的方法应该是根据不同类型的攻击行为，提供更具体的检测思路、规则样例和判断标准。例如，对于异常进程执行、持久化机制、凭据访问等不同场景，需要分别考虑其关键行为特征和正常业务中的常见情况。

问题三：AI 可能过早给出安全结论。 检测到异常行为，并不等于确认发生攻击。如果缺乏足够的上下文，AI 可能将正常管理行为判断为恶意活动，也可能低估某些真正值得调查的异常。因此，我要求 AI 尽量基于可观察到的证据解释判断，而不是仅给出“安全”或“危险”的结论。当证据不足时，应明确标记为“需要进一步调查”，而不是强行给出确定答案。

这些问题让我逐渐认识到：真正决定 AI 能否稳定用于专业工作的，不只是模型本身的能力，更重要的是专业知识如何组织、任务约束如何设计，以及如何建立有效的验证和反馈机制。

如果你也想做类似的事情，可以从哪里开始？

这套方法适合需要持续处理专业信息、编写规则或代码，并且具备可验证执行环境的技术人员。对于网络安全工程师而言，并不需要一开始就建设完整的自动化平台。我更建议从一个具体、可重复的小任务开始。

例如，选择一份公开的网络攻击分析报告，尝试让 AI 完成三个步骤：

1. 提取报告中的关键攻击技术及可观察行为；
2. 根据指定安全平台的语法要求生成一条检测规则；
3. 在测试环境中执行规则，记录错误并反馈给 AI 修改。

当这个小流程能够稳定运行后，再逐步加入定时情报收集、Skill、API 自动执行和检测结果辅助分析等能力。在此过程中，建议保留人工复核机制，尤其是在规则正式投入生产使用、判断潜在安全事件或涉及敏感业务数据时。此外，企业内部的日志、资产信息和安全调查数据可能包含敏感信息，使用外部 AI 服务时，应遵守企业的数据安全要求，优先采用经过批准的模型、接口和数据处理方式。

在这次实践中，我最大的感受是 AI 的价值不只是替我们完成某一项任务，而是让我们有机会重新设计完成这项任务的方式。过去，我需要自己完成从信息收集、技术分析到规则编写和结果验证的每一个步骤。现在，我更关注如何将这些工作拆分成清晰、可复用、可验证的环节，让 AI 承担其中适合自动化的部分。这也让我逐渐从单纯使用 AI 工具，转向思考如何将自己的专业知识和工作经验转化为 AI 能够执行的流程。

对于专业技术人员来说，AI 并不会让专业知识变得不重要。恰恰相反，只有真正理解业务问题、技术原理和质量标准，才能知道如何指导 AI，以及如何判断它的结果是否可靠。

我认为，AI 带来的重要改变是让专业人员从大量重复性执行工作中释放出来，把更多时间投入真正需要经验、判断力和创造力的事情。

32 当政务文书遇上大模型：政务建议性文本的 AI 智能化实践

案例背景与定位

「人工智能+政府建议性文本」应用：面向代表委员撰写辅助、社情民意热点分析、建议性文本质量评估、审查工作辅助与领导决策协商五大场景的智能化平台。

业务痛点与建设目标

政府建议性文本是履行民主监督和参政议政职能的重要方式，建议性文本质量直接影响政府履职成效。对照新时代政府的工作要求，之前的政府建议性文本管理子应用在提升建议性文本质量方面改进空间较大：撰写缺乏专业指导、社情民意收集方式效率低、质量评估主观性强、审查靠人工逐行查阅、领导决策缺乏数据支撑。该项目利用大语言模型与 NLP 技术，构建了覆盖「建议性文本撰写辅助、社情民意热点分析、建议性文本质量智能评估、审查工作辅助、领导决策和协商开展」五大场景的 AI 应用，全面提升建议性文本质量、审查效率与决策协商的智能化水平。

传统模式的五大瓶颈

在使用 AI 之前，这个问题无法有效解决：只能不断地对代表委员进行培训，代表委员也只能不断地去跑数据问情况，政府部门只能人工地去审核这些建议性文本。具体问题：

1. 建议性文本撰写缺乏专业性指导：部分代表委员信息获取渠道有限、调研能力不足，撰写存在文章结构不规范、思路不严谨、专业性不强、针对性不足等问题；
2. 社情民意结合不够精准：收集社情民意存在效率低、覆盖面窄、时效性差等问题，难以全面、精准地反映政策方向、社会问题、群众诉求；
3. 建议性文本质量评估主观性强：传统评估主要依靠人工经验，缺乏客观、科学的评估标准和方法；
4. 建议性文本审查效率有待提高：传统审查依靠人工逐行查阅内容、对比分析，难以适应建议性文本数量不断增长的需求；
5. 领导决策和协商开展缺乏数据支撑：领导缺乏对建议性文本内容的全面了解和深入分析，难以精准把握某一类主题建议性文本的核心内容和价值。

AI 解决方案：五大场景设计与工程实践

五大场景的 AI 应用设计：

1. 建议性文本撰写辅助场景：①智能问答帮助：基于海量数据训练的大语言模型，对代表委员咨询的撰写问题进行讲解回答，提供写作思路建议，可一对一辅导培训；②智能撰写指导：根据选题方向提供政策文件、调研报告、典型案例等参考资料，结合建议性文本结构、逻辑、语言规范要求提供整体大纲；③智能内容生成：自动生成建议性文本建议框架（标题、背景、目标、建议、可行性、执行、参考资料来源），按需调整修改。
2. 社情民意热点分析场景：①智能选题推荐：对社情民意文本数据深度学习，分析社会问题、政策方向、群众诉求，提供精准选题推荐；②热点话题识别：识别当前社会关注热点话题并跟踪分析，形成建议性文本建议；③民意基本分析：情感分析技术进行情感倾向分析，提供更全面客观的信息。
3. 建议性文本质量智能评估场景：①构建质量评估模型：文本主题分析分类，构建质量评估模型并评分；②内容深度分析：提取关键词、主题、观点，分析整体结构特点，肯定优点、对不足提出改进建议；③价值评估：利用向量数据库和知识库，分析语义清晰度、数据支撑度、语言规范度，为采纳和办理提供决策支持。
4. 建议性文本审查工作辅助场景：①智能相似度查重：文本相似度计算算法查重，识别重复建议性文本，及时辙案和退回处理；②智能文本信息提取：信息抽取技术提炼关键信息并生成 300 字左右摘要，便于审查组快速掌握内容；③智能文本数据筛选：NLP 分析快速筛选出符合政府工作报告中心思想、围绕市委市政府中心工作服务大局的优质建言资政内容。
5. 领导决策和协商开展场景：①建议性文本数据分析：文本分析技术提取关键词、主题、观点，生成擅长领域的优秀建议性文本作者可视化图表；②趋势预测：机器学习分析建议性文本数据，预测某一主题的发表趋势；③协商方案推荐：根据建议性文本内容和领导需求检索分类呈现，便于掌握某项工作的实时动态，科学制定下一步协商方案。

AI 应用从实验室走到生产环境的「工程鸿沟」：

总结：成功的 AI 部署，必须平衡好数据质量、工程效率、业务价值这三者的关系。

落地成效：新旧方案数据对比

1. 突破建议性文本质量提升的瓶颈：应用通过智能问答、撰写指导、社情民意热点分析、规范框架生成等功能，为代表委员提供专业指导和写作辅导，弥补调研能力不足的短板，确保建议性文本的规范性、科学性和可操作性，有效提升建议性文本质量，文本的撰写时间大幅度缩短，由之前的每篇三到四个月缩短为每篇一个月。
2. 突破建议性文本审查效率的瓶颈：利用文本相似度查重不再需要审查人员逐篇人工对比，大幅度缩短审查时间、减少错判和遗漏；自动总结概括形成统一规范的摘要提供给领导；NLP 分析快速筛选符合市委市政府重点工作的建议性文本，为审查组选取重点建议性文本提供依据，查重准确率达70%，筛选准确率85%。
3. 突破领导决策和协商开展的瓶颈：为政府领导提供全面、客观、准确的建议性文本数据支撑——筹备政治协商前可快速获取特定主题的建议性文本履职情况概览，统计相关主题数量、评估深度与质量、识别并推荐在该主题上具备卓越见解和撰写能力的代表委员，帮助领导精准把握形势、灵活调整工作策略，以数据驱动引领政府建议性文本工作迈向智能化、高效化，之前领导审核提案需要全量逐篇逐字审查，看完一年的文本，需要近一个月，现在有 AI 代劳，一天之内便可以掌握全局情况。

经验总结与启示

1. AI 落地是一套系统工程：从数据质量、模型选型、工程部署到评估运维、期望管理，任何一个环节掉链子，生产环境都会「翻车」，数据、工程、业务价值三者的平衡是成败关键。
2. 合规与信任是政务类 AI 的生命线：隐私数据必须脱敏、知识库必须热更新、答案必须可溯源可解释，没有出处就没有信任。
3. 从「辅助人」切入先交付：明确 AI 边界、管理业务方预期，先做价值明确、风险可控的场景，再逐步扩展，是政务场景稳妥落地的路径。

33 开发面向企业 HR 和行政组织部门的人才培养智能体产品

作者按： 本文是企业人才培养智能体项目实践，围绕“帮助客户为一类岗位建立内部培养方案”这一业务场景，介绍产品设计与开发实践；文中运行样例来自开发环境验证。

做成了什么：一套供企业客户使用的人才培养产品

我是 William-王吕，来自极客时间研发部，参与开发企业人才培养智能体。产品面向企业客户的 HR、行政组织及人才发展部门，帮助他们梳理岗位标准、明确胜任岗位所需的能力，再把能力要求展开为培养内容。客户提供本企业的职责材料、规范和模板，在产品里确认关键事项，由 AI 工作组承担资料整理、研究、撰写和评审，最后获得可继续讨论和使用的正式文件。

目前项目已实现招聘 JD、岗位说明书和岗位胜任力模型三类任务入口。人才培养的主要路径是：先讲清岗位做什么，再明确需要什么能力、各级做到什么程度，并按需要编排课程建议。客户可以将前一步形成的岗位文档作为后一步的输入材料，逐步建立培养方案；招聘 JD 则服务相邻的岗位需求表达场景。

为什么值得做：客户需要把培养要求落到具体岗位

企业安排内部人才培养时，需要回答一连串问题：这个岗位承担哪些工作？不同层级要交出什么结果？支撑这些工作的知识技能是什么？培训内容怎样与之对应？材料往往分布在岗位说明、企业制度、职级和绩效标准中。HR 或行政组织部门需要协调业务负责人解释职责，再与培训人员一起整理，才能形成可讨论的培养方案。

我们选择从这条业务链入手。客户的困难既有大量重复整理，也有需要业务判断的内容：同名岗位在不同企业的职责不相同，一门课名称相近也未必支撑目标能力。产品设计要让 AI 接手适合整理和展开的部分，同时把企业事实与关键取舍交给客户确认。

怎样把 AI 做成产品：让客户能操作、能判断、能交付

**把客户材料和交付口径作为起点。**我们把企业信息、材料上传、模板配置和任务盘点做进产品。客户可以提交岗位说明、岗位清单、企业规范、职级或绩效材料；系统整理后，先核对本次岗位与输出范围。客户已有模板时，可以在企业配置中导入、确认并管理版本。缺少的企业事实会被指出，业务部门有机会在内容展开前补充。

**用分工明确的工作组完成任务。**客户主要与组长沟通，组长根据当前业务阶段协调专家。岗位说明任务由企业规范、行业研究、撰写和质检专家配合；胜任力任务由依据检索、能力建模、课程方案和质检专家配合。各环节接收明确输入、留下阶段产物，界面呈现交接和进展，客户可以看清哪一步已经完成、哪里还需要自己处理。

**把重要决定放在确认卡上。**在胜任力建模中，产品先给客户能力候选，确认后再展开各级行为和知识技能。候选名称、分类或覆盖范围有问题，客户可以要求调整。正式交付前，客户能查看完整内容、校验事实和评审意见，并选择继续修订或确认定版。HR 和行政组织部门负责组织这项工作，具体岗位尺度仍需业务负责人参与审阅。

**把培养内容接到能力要求上。**课程方案专家根据确认后的能力层级和知识技能，编排学习单元、课程名称、内容类型、学习方式、要点和建议课时，保留对应关系。客户能从一条岗位要求追问到支撑它的学习内容，并检查课程是否包含练习、交付物和复核方式。例如，需求记录这项技能对应的实操建议，会要求学员输出带来源的需求条目清单并提交导师复核。

**让依据和企业差异进入结果。**产品以客户上传材料为基础，按配置使用已开放的专业知识源和公网检索，并保留来源、假设及缺口。缺少绩效或晋级标准，就需要客户补充或审阅推断。企业模板规定字段、层级和业务规则，系统据此校验；AI 对内容适配性的判断作为评审意见呈现，让客户知道哪些是可核对的事实，哪些还需要讨论。

**把连续处理和正式文件也做好。**我们将任务阶段、待确认事项和交付版本保存在服务端，支持客户回看历史、定位当前工作并继续处理。企业配置和会话材料受权限与归属检查约束。正式 Excel 预览读取已保存的交付文件，便于客户核对预览与下载内容。这样，客户的审阅对象有明确的内容、状态和版本。

效果怎样判断：先核实产品完成了哪些工作

目前可核实的成果，是客户使用的材料输入、任务分工、人工确认、质量审阅和文件交付已形成完整产品流程。为了检查这条流程，我们回看了开发环境中“AI 全栈开发工程师”的一次完整任务：上传岗位说明书，选择“能力模型 + 课程”，确认 8 项候选能力，按评审意见修订，再确认正式版本。

该样例的第 3 版包含 8 项能力、24 个能力层级、146 个知识技能点和 109 条课程建议，正式工作簿包含“能力模型”和“校验事实与评审意见”两张表。预览中仍保留 5 条校验事实和 22 条评审意见；这些信息让客户能够继续检查和修订。109 条课程是培养方案建议，后续还需要选用资源、开发内容和组织实施。

本次复核实际读取了已保存的正式工作簿预览，确认交付文件存在且包含上述内容。从上传材料到正式下载卡的记录间隔约 16 分 48 秒，包含会话内的等待、确认和修订。这是一次开发环境验证数据，可用于说明流程和交付结果；客户侧的效率与培养成效，需要另按真实业务任务衡量。

衡量客户价值时，我们关注三个方面：HR、行政组织和业务部门能否围绕同一份岗位标准沟通；培养负责人能否把能力要求落实到学习内容；客户能否方便地审阅、修改并使用交付物。当前尚缺同难度人工任务的完整计时、客户持续使用样本和培训实施后的结果数据，因此不在本文给出提效比例、成本节省或人员能力提升幅度。

开发中遇到的问题：生成内容之后，还要让客户用得起来

**培养方案写得详细，依据仍可能不足。**开发验证中，结果提示部分材料片段不完整、共享知识库零召回；有的分级要求需要绩效和职级材料进一步支持。因此，产品保留来源、假设和缺口，让客户回到原件核对并补充。企业自己的职责边界和制度，需要有掌握事实的人确认。

**课程看起来相关，练习方式却可能不合适。**一条实际评审意见指出，课程要求设定灰度放量与回滚阈值、完成演练，却被归为“原理概念类、在线学习”。这种问题提示我们，评审要检查能力、行为、知识技能和课程之间的对应，培养负责人还要判断练习条件、师资与验收物是否具备。产品因此同时保留规则校验与内容评审，供客户逐项判断。

**交付需要清楚的范围。**当前项目已实现岗位说明、胜任力模型及课程建议等能力；专家萃取、成品课程开发和岗位认证在产品规划中仍标为研发中。现阶段的产品支持客户建立培养依据和方案，实际员工差距识别、课程实施及培养成效确认，需要客户结合业务数据和人员表现继续完成。

别人怎样开始：围绕客户的一项完整业务做产品

如果也要开发面向企业的 AI 产品，建议先选“为一个具体岗位建立培养方案”这样能核对输入与交付物的任务。与 HR、行政组织部门及业务负责人一起确认材料、判断节点和验收方式，再决定让 AI 承担哪些步骤。先让一个任务完成材料输入、候选确认、内容审阅、修订与正式文件交付，再逐步扩展岗位和场景。

客户试点时，可以选择一个业务负责人熟悉的岗位，准备职责、任职要求、绩效与职级标准，以及希望采用的模板。先检查一条真实职责能否对应到能力、层级和学习内容，再由培养负责人挑选一部分建议组织实施，记录人工投入、修改原因和业务反馈，为后续改进提供依据。

34 2 万条古文数据 + 1000 条偏好数据 + 数百道分层测试题：从 4B 通用模型到国学垂直大模型的工程化复盘

案例简介

2025 年我创业做国学文化垂直大模型，遇到两个实际困难：

• 通用模型不是为古文设计的——敦煌写本里的俗字会被切碎成更多碎片，模型能看到的词元数量膨胀约 3 倍；而断句、文白翻译、出处溯源这类任务，市面上没有现成的高质量古文训练数据，通用模型开箱即用做不好；
• 真正的成本不在训练，在训练之前：语料清洗、出处核验、生僻字考订、数据隔离、出题测试，这套活在过去是几个人月的团队工程——自建成本高，外包质量不可控。

我把「数据→训练→测试」拆成一步步可复查、可自动校验的工序，关键判断交给程序规则加人工抽查：指令微调训练集 2 万+条、偏好数据 1000+条、分层测试题数百道，用开源底座 Qwen3.5-4B 完成多轮迭代训练，形成覆盖通用底座适配、领域数据工程、训练与评测的完整流程。

之前的老方案是什么，存在什么问题

1. 人肉硬啃：清洗、核验全人工，几个月才出一版数据，换人即不可复现；
2. 外包协作：质量不可控——我们自己的旧训练管线甚至出过伪造训练曲线的情况，看着跑完了其实没跑。

所以问题不是「怎么调模型」，而是怎么把数据、训练、测试全流程做成可复查、可验证的工程，每个环节都敢让别人点开查证。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

思路：把「数据→训练→测试」拆成一步步可复查、可自动校验的工序，关键判断交给程序规则加人工抽查，不靠感觉。

1. 数据：同一份数据每次重建结果完全一致，训练数据和论文实验数据彻底分开，几十条校验规则自动把关，缺一条不进下一步；
2. 质检：程序扫全量、人只看拿不准的，只有几十条拿不准的才转人工；
3. 校验：拿《四库全书总目》约 1 万条书目和部类目录逐条对，当场抓出归错类的书；
4. 训练：用开源底座 Qwen3.5-4B，先拿海量古文做指令微调，再用偏好数据教它什么该答、什么不会就承认不会，最后用强化学习压错误；研究上还试了双曲几何微调——古籍知识本来就按经史子集树状分层，主流微调方法不适配这种结构，双曲几何更贴合，50+ 组对照实验已验证。

过程中踩过的坑：

1. 防「假装成功」比求快重要——我们自己的旧管线出过伪造训练曲线，第一纪律是宁可明确报错，不能静默糊弄；
2. 别迷信 AI 合成数据——用合成引擎跑过 2 万+条「质检合格」的语料，最后发现没有来源、没有授权、没有查重，既成不了壁垒也过不了监管备案的材料审查，果断弃用，改为只收录来源和授权都可追溯的公版语料，每条数据都能对回底本和出处；
3. 每个数字都要敢让人查，证伪不了的句子删掉不可惜；
4. 垂直模型的壁垒是数据工序不是训练技巧——同样的底座和配方，差别在谁敢把数据怎么来的全部公开。

与旧办法相比，新办法的结果如何（数据对比）

1. 数据：指令微调训练集 2 万+条（覆盖问答、出处溯源、文白翻译、古文断句四类），偏好数据 1000+条，分层测试题数百道；
2. 训练：稳定收敛，效果达标；
3. 模型产出：完成多轮迭代，形成覆盖通用底座适配、领域数据工程、训练与评测的完整流程，古文理解与生僻字处理能力相对通用模型有可测提升，评测体系可重复、可回归，后续版本迭代有据可依。

通过这个 AI 落地案例，我的收获有哪些

1. 垂直模型的第一纪律是「可复现、可证伪」：宁可明确报错，不能静默糊弄——伪造训练曲线这种事，毁掉的是整个流程的信任；
2. 数据来源与授权是壁垒也是合规底线：合成数据再多，没有来源、没有授权、没有查重，既成不了壁垒也过不了备案审查；只收录可追溯的公版语料，每条数据都能对回底本和出处；
3. 垂直模型的壁垒在数据工序而非训练技巧：同样的底座和配方，差别在谁敢把数据怎么来的全部公开——工程化的数据、训练、评测流程，才是别人抄不走的部分。

35 把「盯屏」交给视觉决策模型：CCTV 异常事件实时预警的一次落地实践

先用一段话说清楚，我做成了什么

我是某大型维安领域公司的算法工程师，日常需要为承担公共服务的国央企客户研发数十路摄像头的实时异常监控方案。

过去采用“外包人力轮巡盯屏＋人工定期巡逻”的方式，主要问题是后半夜注意力衰减、异常发现和上报链路太长，小事件容易拖成大事故。

从去年开始，团队尝试用本地部署的视觉决策模型辅助完成数十路摄像头的实时异常判断。

经过两版方案迭代与现场试点，目前的结果是：单卡可在三秒内解析二十路画面，人流骤增、拥堵推搡、打架追逐等疑似事件能自动提醒值班人员，响应速度和误报情况都有改善；其中仍需人工完成的是报警复核、现场处置，以及少量长尾场景的兜底。

原来怎么做，为什么值得改变？

先说背景。团队在一家大型安全服务企业的业务组负责 CCTV 方向，集团希望我们部门实验并引入各种 AI 技术，为承担公共服务的国央企客户提供更有竞争力的服务。客户也同意“希望引入视觉 AI 做实时监控提醒”后，这件事落到了我们组。

以其中一个试点客户为例：他们在火车站、汽车站和人群密集的广场部署了数十路摄像头，要实时监控人流量突然变大、人群拥堵推搡、追逐打闹甚至打架抢劫等治安事件，也要盯住车辆容易拥堵的路段。

这项工作过去由外包人力完成：值班团队 7×24 小时轮巡盯住数十路画面，另有人定期巡逻关键路口和摄像头死角。最麻烦的环节有两个。

• **一是“人盯屏幕”的稳定性。**一个人同时盯几十路画面，连续值守几个小时难免精力不集中，后半夜尤其严重——而治安事件恰好多发生在后半夜。比如某个人流通道夜间出现人群聚集推搡，值班员可能正在处理另一路画面，等注意到时已过去几分钟。
• **二是“发现—上报—处置”的链路太长。**值班员看到异常后要用对讲或电话通知巡逻人员，沟通不畅就会延迟响应。小情况遏制不及时，就可能升级成重大事故，这是客户最担心的。

客户也尝试过自己引入 AI：本地部署的小模型跑得快但结果不稳定；大模型识别准，但推理慢、对硬件要求高，要满足实时就得投巨资升级方案。

此外还有两条硬约束：合规上数据不能出域、不能用外部模型；现场不接受对存量设备和网络做大规模改造，能用的只有有限的本地算力。

这两条约束叠加“数十路、实时”的要求，是方案设计的全部前提。

我们具体怎样把 AI 用进去？

我们选了一个有代表性的点位推进：在不换设备、数据不出域的前提下，为某枢纽站点的数十路存量摄像头做出“能实时提醒、误报可接受”的方案，分六步推进。

第一步：先用微调小模型当“报警器”，摸清单模型路线的边界。

第一版方案，我先准备了一个微调过的轻量视觉模型，交给我们自己的推理服务，要求它对单路画面做异常检测、发现疑似情况就提醒值班人员。它给出的结果是：速度够快，单摄像头勉强能实时，但误报非常多。

我发现问题的根源不在模型精度，而在单角度摄像头容易被遮挡、信息残缺——值班人员被无效报警反复打扰，反而开始麻木。于是我放弃“换更准的模型”，确认要换思路，进入下一步。

第二步：转向视觉决策模型，先给候选模型办一场“入场考试”。

我先准备了一个由几百张图像组成的评测数据集，覆盖不同人数规模、打架、推搡、拥堵、车辆滞留等场景，交给候选的视觉语言模型（VLM）逐个跑测，要求它们既看得清画面、又认得出目标现象，且参数量小于 9B——现场只给得起显存 24GB 的单卡。它给出的结果是：大部分候选被淘汰，有的视觉能力差，画面里明明有人群推搡却视而不见；有的看得清，但对“打架”“推搡”这类现象识别很弱。

我发现“能对话的模型”不等于“能看监控的模型”，于是把通过初筛的模型针对特定任务做后训练，再部署到客户环境测试，进入下一步。

第三步：设计“一次调用、多题联答”的提问方式。

我先梳理出值班场景真正关心的问题清单，交给决策模型，要求它对每张画面一次回答多道题目，并输出带置信度的 JSON。以下是我们实际使用的一版提示词（脱敏）：

【输入】一张 CCTV 画面截图（单帧）。

【请回答以下问题，并输出 JSON】
1.（choice）画面中的人数区间：
   A. 20人以下　B. 20–40　C. 40–60　D. 60–80　E. 80–100　F. 100人以上
2.（bool）是否存在打架斗殴？true / false
3.（bool）是否存在推搡或拥挤？true / false
4.（bool）是否存在追逐打闹？true / false
5.（bool）是否存在车辆拥堵或滞留？true / false

【输出示意】
{
  “count_range”: “B”, “count_confidence”: 0.92,
  “fight”: false, “fight_confidence”: 0.97,
  “push”: true,  “push_confidence”: 0.61,
  “chase”: false, “chase_confidence”: 0.95,
  “vehicle_jam”: false, “vehicle_jam_confidence”: 0.90
}

它给出的结果是：人数区间判断相当稳定，但“推搡”和“拥堵”在低清画面里容易互相混淆。

我发现把两类现象合在一起问会互相干扰，于是人工拆成两道独立的判断题；像上例中“推搡”置信度只有 0.61 的低置信结果不直接报警，转给第五步兜底复核。这样每路画面一次推理就能同时拿到人流量分级和行为判断，批量解析成为可能。

第四步：用多角度交叉验证压制误报。

我先准备了同点位多角度摄像头的画面关联关系，交给决策模型的复核流程，要求它在正面角度报出异常后，自动调用其他角度做二次取证。它给出的结果是：其他角度都没有类似结果的报警被降级或不推送，误报进一步收敛。

我发现这一步本质上是把“单角度信息不全”的短板从模型层面转移到流程层面解决，于是固化为标准动作，再进入下一步。

第五步：给长尾场景配兜底

我先准备了一个此前训练好的常规视觉模型常驻内存，交给兜底链路，要求它每 3～5 秒对全部画面抽帧探测一次；决策模型置信度低于阈值时，也把画面转给它复核。它给出的结果是：长尾场景（严重遮挡、罕见行为）有了第二道防线。

我发现决策模型的软肋是单步推理、“想得浅”，单靠它兜不住所有情况，于是保留了这条旁路；同时我们仍在收集更大的数据集，尝试基于 MOE（混合专家）架构的决策模型进一步提高可靠度。

AI 与人工的分工如下（脱敏流程示意）：

[数十路存量摄像头]
        │
        ▼
┌────────────────────────────────────────┐
│ 决策模型批量推理（单卡，秒级/轮）              │
│ 每路输出：人数区间 ＋ 行为判断 ＋ 置信度        │
└──────┬─────────────────────────────────┘
       ├─ 无异常 ───────────────→ 不打扰值班人员
       ├─ 异常 且 置信度 ≥ 阈值
       │      └→ 同点位其他角度交叉复核 ──→ 推送报警
       └─ 异常 且 置信度 < 阈值
              └→ 常驻常规视觉模型兜底复核 ──→ 推送报警
                                        │
                                        ▼
                      【人工】值班员复核确认 → 通知巡逻处置
旁路兜底：常规视觉模型每 3～5 秒抽帧探测全部画面
运维看板：健康指示灯/图标 ← 模型与宿主机心跳状态

第六步：把“系统活着”本身也纳入设计。

我先复盘了模型在生产环境中崩溃的事故，交给运维环节一个朴素的要求：让值班人员一眼能看出系统是否正常。它给出的结果是在现场加了健康指示灯/图标，并培训现场人员：指示灯不亮时，要更依赖人工盯屏和巡逻。

我发现最危险的不是模型答错，而是模型“不在场”却没人知道——崩溃后没有任何警报，值班人员会误以为“一直没情况发生”，这种假安全比误报更致命。

有没有效果，我是怎么判断的？

先坦白：这是客户环境中小范围试点的持续运行；没有做严格的对照实验，也没有“误报率下降百分之多少”这类精确数字。判断依据有三个。

• **一是前后两版方案的对比。**比较基于同一批存量摄像头、同一套值班流程，前后任务难度和质量要求基本一致。V1（微调小模型报警器）误报频发，值班人员开始忽略报警；V2（决策模型＋多角度复核＋兜底）上线后无效打扰明显收敛，值班人员的反馈是“打扰少了，报警更值得看一眼”。
• **二是响应速度。**现场单卡环境中，二十路画面三秒内完成一轮解析，基本达到“秒级发现”的目标。要说明的是：这是纯推理时间，不包含人工复核——报警后的人工确认并没有省掉，我们的目标始终是“把人的注意力从盯屏转移到确认”，而不是取消人。
• **三是选型阶段的批量测试。**几百张图、多个候选模型逐个跑完对比，谁能看清画面、谁对特定现象识别弱，排序依据非常明确。

需要诚实说明：以上主要依据是试点运行观察和值班人员反馈；误报次数、平均响应时长等指标仍在持续收集，样本量还小，结论只能算初步成立。

哪里不好用，我踩过什么坑？

第一个坑是最初的方法没有奏效。

小模型报警器勉强能实时，但单角度遮挡加上模型能力受限，误报多到值班人员开始麻木。这个坑教会我：报警系统最常见的失败不是“漏了大事件”，而是“报得太勤，没人再信”。

第二个坑是对“决策模型”的盲目信任。

我一度以为“能对话的模型就能看监控”，实测才发现并非如此。发现问题靠的就是那套几百张图的评测集——它在部署前淘汰了大部分候选模型。此后我们固定下“先评测、再后训练、后部署”的动作，每引入新模型第一件事就是跑评测集。

第三个坑是崩溃静默。

模型在生产环境崩溃过，宿主机上还有别的程序竞争资源；崩溃后没有任何报警，值班人员会误以为“没有情况发生”。目前的应对是健康指示灯加现场培训，但坦白说这仍依赖人员主动留意；把它升级成心跳丢失自动告警，是我们下一步要做的。

还有一些情况仍由人工处理：高风险事件（疑似打架、抢劫）即使模型报警，也必须由安保力量现场确认后升级处置；需要连续行为判断或严重遮挡的场景，主要靠常规模型探测和人工巡逻兜底。

如果你也想做类似的事情，可以从哪里开始？

这个方法适合有存量摄像头、数据不能出域、算力有限（单卡级别）的安防或运维团队，在需要“发现异常、提醒人工”而不是“自动处置”的条件下使用。

开始前需要准备三样东西：一份写清楚“要模型回答什么”的问题清单、一个几百张图规模且覆盖目标场景的评测集、一个随时待命的常规小模型做兜底。

第一次尝试，建议先拿“单摄像头人数区间统计”这种单问题、容易验证的小任务练习，跑通后再加行为判断题，然后是多角度复核和置信度兜底。遇到高风险事件、大范围遮挡、夜间低照度画面等情况时，需要人工介入，或者暂时不适用——先去积累数据，而不是硬上模型。

最后，我想分享给大家的话

做了两版方案后，我最大的体会是：AI 落地的难点往往不在“模型能不能做到”，而在**“把什么交给模型、把什么留给人”**。我们做的监控只是很小的一块——从车流车道、低空到工厂流水线，依托 CCTV 和视觉判断模型的机会还有很多，但每个场景都需要小心探索，几乎不可能有哪一项技术覆盖所有场景。

我的另一条经验是：模型是死的，场景是活的。能力最强的模型未必适配我们的场景，挑一个基础能力、硬件开销和响应速度都“够用”的模型，针对特定场景做适配，往往才是更合理的方案。

36 从「人工检索 Wiki」到「AI 智能问答」，用 AI 搭建企业内部技术支持 Copilot

案例简介

企业内部技术支持 Copilot：基于 RAG 架构把 Confluence/GitLab Wiki 静态文档变成动态知识库，实现「输入问题 → 精准解答 + 原文溯源」。

研发团队日常开发与新人入职时，经常需要在内部技术文档里检索和排查问题。随着业务发展，团队在 Confluence、GitLab Wiki 上沉淀了上千篇技术文档（含架构设计、API 手册、排障指南等）。开发者在遇到报错或需要对接老模块时，传统搜索只能基于关键词匹配、无法理解意图，经常搜出一堆无用信息。我用 GLM-4 + LangChain + Chroma + FastAPI 搭了一套 RAG 架构的企业内部技术支持 Copilot，把内部静态文档转化为动态知识库，通过语义检索 + 大模型归纳，输入问题直接输出精准解答及原文出处：技术问题排查时间从平均 30 分钟降至 3 分钟内，人效提升超 80%，技术群基础求助消息减少约 60%，新人上手周期从 2 周缩短至 1 周。

之前的老方案是什么，存在什么问题

遇到问题先靠关键词在内部 Wiki 搜索，搜不到就在技术群里 @ 相关负责人询问，或者直接走到对应同事工位边问。弊端：

1. 搜索效率极低，且强依赖个人的关键词提取能力；
2. 知识传递属于「口口相传」，没有沉淀；
3. 严重挤占资深工程师的时间，据统计每天有 1-2 小时被消耗在解答重复性问题上。

是怎么用 AI 解决的，具体过程是什么（以及这中间有哪些坑）

工具/技术：GLM-4 API（大语言模型）、LangChain（编排框架）、Chroma（向量数据库）、FastAPI（接口服务）。

整体思路：采用 RAG（检索增强生成）架构，将内部静态文档转化为动态知识库，通过语义检索 + 大模型归纳，实现输入问题直接输出精准解答及原文出处。关键步骤：

1. 数据处理：编写脚本批量拉取 Confluence/GitLab 文档，清洗 Markdown 标签，按段落进行 Chunk 切分；
2. 向量化入库：调用 Embedding 模型将切分后的文本块转化为向量，存入 Chroma 向量数据库；
3. 语义检索与重排：用户提问时，先将问题向量化，在数据库中召回 Top-5 最相关的文本块；
4. 大模型生成：将召回的文本块作为 Context，结合预设 Prompt（「你是一个资深架构师，请根据以下资料回答问题，如果资料中没有答案请明确说明…」），调用 GLM-4 API 生成最终答案，并在末尾附上文档链接。

过程中踩过的坑：

1. Chunk 切分粒度坑：最初按固定字数（500 字）切分，导致代码块或上下文被割裂，AI 回答驴唇不对马嘴。→ 经验：切分时要结合 Markdown 的层级结构，遇到代码块或表格要整体保留，并保留上一级的 Heading 作为元数据。
2. 大模型幻觉坑：模型有时会「强行回答」知识库中不存在的内容。→ 经验：必须在 Prompt 中加入强约束（「必须基于以下 context 回答，找不到就说不知道」），并在前端展示检索到的原文片段，让用户一键溯源，增强信任感。
3. 同义词与冷门专业词坑：纯向量检索有时会漏掉内部专有名词。→ 经验：引入 Rerank 模型对召回结果做二次重排，效果有质的飞跃。

与旧办法相比，新办法的结果如何（数据对比）

• 检索与解决时效：技术问题排查时间从平均 30 分钟降至 3 分钟内获取有效答案，人效提升超 80%；
• 群内打扰频率：技术群里的基础求助消息减少了约 60%，资深工程师可以将精力集中在核心业务上；
• 新人上手周期：新人熟悉内部系统架构的时间从 2 周缩短至 1 周。

通过这个 AI 落地案例，我的收获有哪些

1. 检索质量决定回答质量：Chunk 切分粒度、Rerank 重排这些「检索工程」细节，比模型本身更影响效果——固定字数切分割裂上下文，AI 再强也答不对。
2. 防幻觉要靠 Prompt 约束 + 溯源展示双管齐下：强约束「找不到就说不知道」，同时把检索到的原文片段展示给用户一键溯源，信任感才能真正建立。
3. 内部知识问答是 RAG 性价比最高的落地场景之一：文档越积越多、基础问题反复被问，Copilot 把资深工程师从重复解答里解放出来，人效提升立竿见影。

37 AI 辅助研发：让课程资料成为智能体可调用的能力

课程资料查询 MCP：让 AI 按需获取可信的课程知识。

我做成了什么

我是开发工程师，这次完成的是一项让 AI 查询内部课程资料的能力。过去，业务人员围绕一个话题寻找课程素材，需要先搜索课程，再逐篇阅读文章或查看视频，找到合适的内容后，手动整理并交给 AI。AI 虽然能够帮助写作，但无法直接取得这些内部资料，资料查找与内容生成之间仍然依赖人工衔接。为此，我将课程资料检索能力封装为 MCP 工具。MCP 可以理解为 AI 调用外部工具的一套标准接口：接入支持 MCP 的 AI 助手后，用户可以直接提出问题或提供参考文稿，由助手调用工具查询相关资料，再基于返回的内容继续工作。

目前，这项能力已经完成接入和实际查询验证，支持检索图文专栏与视频课程中的课程摘要、课时摘要和原文片段。人工仍然负责判断资料是否适合当前任务、核对引用语境，以及审核最终输出。

为什么需要让 AI 直接查询课程资料

以一次技术内容创作为例：业务希望围绕“RAG 系统如何提升召回质量”整理一篇文章，并结合内部课程中的讲解。

如果只把这个话题交给通用 AI，它可能给出一篇结构完整的回答，但回答未必来自我们的课程，也无法保证其中的观点能够在内部资料中找到对应依据。

如果希望使用课程内容，就需要人工完成另一条流程：

1. 搜索可能相关的课程。
2. 打开课程目录，寻找相关课时。
3. 阅读正文或查看视频，定位具体讲解。
4. 摘录资料，再交给 AI 组织内容。

最麻烦的地方不只是搜索次数多，而是业务问题与课程内容的表达往往不一致。用户问的是一个具体问题，课程标题却可能是某项技术或某个知识体系；真正有用的内容，可能只出现在某一课时的几个段落中。

因此，这次建设的重点，是让 AI 在处理业务任务时，能够调用内部课程查询能力，取得相关资料，而不必每次都由人提前找好、复制进去。

我是怎样把这项能力接入 AI 工作流程的

第一步：把业务需要的“查资料”定义成一个工具

我先明确了这个工具要解决的问题：根据用户提供的查询条件，从已导入的课程范围中查找相关资料。

输入可以是一句问题、一个话题，也可以是一篇参考文稿。返回内容分为三种：

• 课程摘要： 帮助用户了解一门课程主要讲什么。
• 课时摘要： 帮助用户判断某一篇文章或某一节课是否相关。
• 原文片段： 提供与问题相关的正文或字幕内容，供后续阅读、引用和整理。

例如，用户可以这样提出请求：

请调用课程资料查询工具，检索“RAG 系统如何提升召回质量”相关的课程原文片段，返回最多 5 门课程。

这里的“最多 5 门”是数量上限，不是必须凑满。如果没有符合条件的资料，工具应当明确返回未命中。

这样，AI 助手就有了一项边界清楚的能力：需要内部课程资料时调用工具，取得资料后再继续完成用户的任务。

第二步：把课程内容整理成适合 AI 查询的知识资料

要让 AI 查得到、查得准，不能只把课程名称放进搜索系统。

我将课程内容组织成课程、课时和原文片段三个层次。课程摘要提供整体主题，课时摘要帮助定位具体知识点，原文片段则保留可供核对的实际内容。

其中，AI 主要参与摘要整理：

• 课时已有正式摘要时，优先使用原有字段。
• 缺少摘要时，根据该课时的正式正文或字幕生成摘要。
• 课程摘要根据课程信息和各课时摘要生成，形成整门课程的内容概览。

摘要用于帮助理解和检索，但不能代替原文。返回的原文片段仍来自正式正文或字幕，不由模型重新编写。

视频课程也纳入同一套查询流程：优先使用人工上传的字幕，没有可用人工字幕时，再使用正式来源中的 AI 字幕。这样，用户不必先区分某个知识点来自图文还是视频，而是可以围绕自己的问题统一查询。

本次支持范围明确限定为图文专栏和视频课程，其他课程类型不作默认支持。

第三步：同时考虑“意思相关”和“关键词准确”

实际测试中，我发现，仅依靠语义检索并不总能满足业务需求。语义检索擅长寻找意思相近的内容。例如，用户询问“怎样让知识库找得更准”，相关课程可能使用的是“召回质量”“检索优化”等表达，语义检索能够帮助建立联系。但对于产品名称、技术术语和缩写，意思相近并不代表真正相关。因此，我加入了关键词检索，与语义检索共同提供候选资料，再进行合并、去重和排序。这一步的目的，是兼顾两类需求：既能理解自然语言问题，也能重视用户明确写出的关键词。在原文片段模式下，同一门课程命中的多段内容会聚合展示，便于用户集中查看。无论使用哪种检索方式，最终都应返回与查询相关的资料，而不是仅仅返回“系统里最接近的几条”。

第四步：通过 MCP，让查询能力进入 AI 对话

完成底层检索后，我将它接入 MCP，让 AI 助手能够在对话过程中调用。

业务使用时不需要知道资料存在哪个库，也不需要直接操作接口。用户说明任务，助手发起查询，工具返回资料，助手再根据当前任务进行整理。

除了简短问题，我还使用整篇参考笔记测试了这条流程：

请把这篇参考笔记作为检索条件，查找相关课程原文片段，返回最多 5 门课程。

这种方式适合业务已经有初稿、希望补充内部知识素材的场景。工具负责提供候选资料，AI 助手可以进一步归纳，人工则判断哪些内容值得采用、是否存在断章取义。

课程资料查询 MCP 因而成为了连接业务问题、内部课程和 AI 助手的一层服务。

效果体现在哪里，我是怎样判断的

我主要通过具体技术问题和完整参考笔记两类输入进行实际验证，关注三个方面。

第一，AI 是否能够真正调用内部资料。 不再只是要求模型“结合我们的课程回答”，而是有明确的工具调用和资料返回过程，可以检查它实际取得了什么。

第二，返回的内容能否支持后续工作。 课程摘要适合判断方向，课时摘要适合缩小阅读范围，原文片段适合进一步核对与整理。不同任务可以选择不同粒度，不必始终得到同一种结果。

第三，资料来源和能力边界是否清楚。 摘要与原文分别呈现，未命中与服务异常分别处理，避免让用户误把模型概括当成原文，或把调用失败理解成没有相关课程。

目前可以确认的是，课程资料已经能够通过 MCP 被 AI 查询和获取。对人工查找时间、检索准确率以及内容采用率，还没有进行系统化的前后对照统计，因此不使用具体的效率提升比例。

下一步更有价值的评估，是持续记录真实业务问题，检查返回资料是否相关、是否被采用，以及人工还需要补充哪些工作。

过程中遇到了哪些问题

1. AI 查到了资料，不代表查对了资料

一次针对具体 AI 产品名称的测试中，检索曾返回其他技术方向的片段。这说明接口调用成功，与结果真正相关，是两件不同的事。

因此，验收不能只看“有没有结果”，还要看返回内容是否回答了当前资料需求。关键词检索和多路结果融合能够帮助改善召回，但仍然需要用真实问题持续验证，不能把一次调整视为准确性的保证。

2. 有视频课时，不代表有可检索的正文

早期处理视频课程时，出现过课时记录已经导入，但没有生成字幕片段的情况。检查后发现，当时只接受人工字幕，部分视频实际上只有 AI 字幕。随后调整为人工字幕优先、正式 AI 字幕兜底。但如果两类字幕都不存在，就不能凭空生成所谓的原文片段。这让我更加明确：AI 能否查到资料，首先取决于是否有合格的源内容。

3. 资料搜索不能等同于完整课程阅读

用户输入课程名称时，系统会把它作为查询条件寻找相关资料。这不等于精确打开该课程，也不保证返回完整目录或全部正文。当前工具的定位是查找相关素材。完整课程目录读取、指定课时全文获取等需求，应当作为独立能力设计，不能让用户误以为现有搜索已经覆盖。

如果你也想做类似的事情，可以从哪里开始？

这个方法适合已经拥有内部内容、希望让 AI 在工作中引用这些内容的团队，例如课程、产品文档、培训资料或操作手册的维护团队。

第一次尝试，建议先选择一个明确场景：

让 AI 为一篇技术文章查找相关的内部资料。

准备一小批来源明确、允许使用的内容，确定需要返回摘要还是原文，再将查询能力接入 AI 工具。随后用几组真实问题测试：既要包含应该命中的问题，也要包含资料库中没有答案的问题。验证重点不应只是“AI 能不能调用”，还应包括资料是否相关、来源能否核对、缺少内容时是否如实说明，以及人工能否据此继续工作。

这次实践对我的启发是：让企业内容进入 AI 工作流程，关键不只是把内容存起来，而是把它做成 AI 能够按需查询、业务能够判断是否可用的知识服务。

38 AI Coding 的下一步不是写得更快，而是可验收：蚂蚁数科 Harness 工程实践

随着大模型能力增强，AI Coding 正从代码补全走向由 Agent 独立执行完整任务。研发团队面对的问题也随之改变：当代码产出速度成倍提升，原有的需求约束、Code Review 和测试验收机制还能否跟上？如果验证能力没有同步升级，AI 带来的可能不只是效率，还有更集中、更难控制的质量风险。

在 AICon 全球人工智能开发与应用大会上，蚂蚁数字科技资深技术专家魏长征结合两个真实项目，分享了团队对这一问题的探索：在一个 40 多万行的 Rust 新项目中，从第一天开始将 Harness 内建进研发流程；在一个超过 60 万行的 C++ 存量项目中，先重建事实源和质量门禁，再让 Agent 参与仓库升级。经过改造，后者的代码缺陷率从 20% 以上降至个位数。

在魏长征看来，AI Coding 并没有创造全新的软件工程问题，而是以更高的产能，将需求模糊、目标漂移、事实冲突和验证不足等旧问题集中放大。Harness 也不是某一种具体技术，而是一套围绕约束、验证和验收建立研发闭环的思路。本文将沿着演讲的逻辑，呈现这套体系如何从实际问题中逐步形成，以及它在新项目和存量工程中的具体落地过程。

AI Coding 最近被频繁提起，但使用大模型辅助编程并不是刚刚发生的事情。

大模型出现不久后，很多团队已经开始尝试让模型写代码。那时还没有成熟的 Agent 工具，大家主要在对话框里提问、粘贴代码，让模型帮忙编写脚本、处理繁杂任务或者分析错误，确实可以节省不少力气。

随后，Cline 等工具开始以插件的方式嵌入 VS Code，大家逐渐在 IDE 中使用 AI。再往后，我们集中采购了 Cursor 一类的 AI IDE，开发者的使用方式从“在 IDE 中安装插件”，变成使用一整套内嵌 Agent 的开发环境。那一阶段，大家使用最多的能力还是 Tab 补全。

到了后来，Claude Code 等终端形态的工具出现，Cursor 的产品形态也发生变化。我们逐渐发现，IDE 可能已经不再是主要战场，对话框反而成为人与 Agent 协作的主要入口。

随着模型越来越强、工具可以完成的工作越来越多，我们交给它的任务也越来越完整。最初只是让 AI 写几行代码，后来则希望它独立完成一项任务，最后由人来验收。

因此，检验标准也在变化。过去，我们关心的是代码写得好不好；后来，需要判断功能是否正确；当 Agent 开始处理工程级任务时，仅仅判断某个模块能不能运行已经不够，还要看它放进整个项目以后，能不能在完整链路中稳定工作。

AI Coding 的产能提升得非常快，但研发团队的验证标准、验证方法和验证工具是否同步跟上了，这是目前最核心的矛盾。

一旦验证能力没有跟上代码生产能力，项目就很容易失控。Harness 工程之所以受到关注，正是因为大家开始意识到，只让 Agent 高速生产代码是不够的，还必须围绕它建立完整的验证闭环。

从早期的 Prompt 工程，到上下文工程、Harness 工程，再到最近讨论较多的 Loop 工程，不同概念反映的是同一个趋势：AI Coding 在研发工作中承担的角色越来越重要，处理的任务也越来越复杂。我们希望 Agent 做更多事情，同时又希望它把这些事情做好。

AI Coding 新范式挑战：从传统研发范式到 AI Coding Loop

AI Coding 经常被称为一种新的工作范式。它的新，首先体现在开发者角色的变化上。

原来我们自己写代码，是代码的生产者；现在代码越来越多地由 AI 完成，我们逐渐变成代码和结果的评判者。再从更大的范围看，有了 AI 工具以后，一个人能够处理的任务跨度、涉及的知识面以及跨角色协作的范围，都会明显扩大。

但我也一直在思考：AI Coding 到底带来了哪些过去从未见过的挑战？

仔细想一想，很多问题并不是 AI 带来的，它们过去一直存在于软件研发过程中。

我很多年前在外企做软件工程师时，一个 Feature 可能并不复杂，但从开发到 Release 需要半个月，其中甚至有一周都在和国外同事做 Code Review，反复讨论实现细节。即使经过这么长的流程，软件仍然难免出现 Bug，但整体发布质量相对稳定。

后来，很多业务进入高速发展阶段。产品经理可能今天提出一个需求，要求三天以后上线。研发人员会觉得很多地方没有写清楚，但为了赶上发布时间，只能根据自己的理解补全。等功能上线以后，产品经理却发现，这并不是他想要的功能。

这就是研发过程中常见的目标漂移。

今天，我们把一项 Coding 任务交给 Agent，最后发现它实现的功能与预期不一致，很容易把原因归结为大模型的幻觉。但在责怪模型之前，也需要先问一句：我们自己的需求是不是也存在“幻觉”？目标、边界和验收标准真的说清楚了吗？

类似的问题在由人完成的软件开发中一直存在。AI Coding 带来的巨大变化，并不是创造了这些问题，而是它的速度太快、产能吞吐太高，所以把问题集中暴露了出来。

一个 Agent 可能在一天之内完成过去三个月才能完成的代码量。原本分散在几个月中的问题突然集中爆发，自然会让人觉得项目里到处都是问题。

本质上，AI Coding 放大的是研发流程中原本就存在的需求模糊、认知偏差、事实冲突和质量欠账。

过去，我们站在开发者的角度，可能会抱怨产品需求写得不清楚，需要自己不断脑补。今天，当 Agent 努力理解我们的任务时，我们实际上站到了类似产品经理的位置。

看清这个底层逻辑之后，解决问题的方向也就比较清楚了。Harness 工程要处理的很多挑战，在过去的软件研发流程中都能找到相应的解决办法。传统研发会做需求评审、架构评审、接口定义、Code Review、测试准出和任务拆解。进入新的工作范式后，我们需要思考的是，如何把这些经验迁移到与 Agent 协作的过程中。

AI Coding 的问题首先是“太快”。既然如此，我们也可以用同样快的方式进行验证。Agent 可以生成代码，也可以参与质量检查和 Code Review。

可以理解为“用魔法打败魔法”：当代码生产速度和验证速度能够匹配，再加上相应的 Harness 机制，就有可能形成类似传统研发的质量闭环，并在这个基础上提高整体效率。

Harness 架构：来源于真实工程实践

在我们的实践中，Harness 并不是一种具体技术，更像是一套验证闭环的思想。

至于 Harness 架构是不是一定要分成某几层，每个项目是不是都要采用同样的 Reviewer，其实没有那么重要。不同项目面对的问题并不相同，很难把一套做法原封不动地搬过去。

即使在我们自己的项目里，这套体系也不是一开始就完整设计出来的。最初并没有想清楚需要多少个 Reviewer，也没有预先决定每个 Reviewer 应该检查什么。更多时候，是随着项目暴露的问题越来越多，团队不得不寻找新的约束方法，最后才逐渐形成一个体系。

因此，从方法论角度所说的五层，更像是一种“马后炮”式的总结：项目跑了两个月，感觉效果不错，再回过头看，发现这些实践大致可以归为五层。它们背后的逻辑并不陌生，因为基本都能在传统软件开发中找到对应。

传统开发在编码前会进行需求评审和架构评审，也会编写架构设计文档和接口定义文档，提前明确任务目标、软件边界和设计约束。这些工作对应的就是约束层。

对抗验证对应的是 Code Review。在高速迭代中，Code Review 本来就可能流于形式，AI Coding 进入以后，这个问题更加突出。过去，一个 PR 超过 2000 行，人工审查已经很困难；现在，Agent 一次可能提交四五千行代码。如果因此直接放开限制，负责 Review 的人很快就会不堪重负。代码提交者自己都没有完整看过，其他人又怎么可能逐行看完？

但 Code Review 本身非常重要，不能因为代码量变大就放弃。我们需要考虑的是，怎样在 CI 流程中让 Agent 参与 Code Review。

证据层对应的是交付验收和质量准出。一次任务能否交付，需要有相应的报告和测试结论，不能只是 Agent 告诉我们“已经完成”。

另外两层围绕状态写入和目标对齐展开，与传统研发中的任务拆解和阶段性评审很相似。比如，把一个任务拆成十个 Sprint，明确每个 Sprint 要做什么，再写入 Backlog。即使中间休假一周，回来以后仍然知道任务进行到了哪里。Agent 也面临同样的问题：如果没有持续记录任务状态，它就可能发生漂移，或者因为上下文丢失而忘记之前做过什么。

具体到约束层，一个项目通常需要规定几类文档。

首先是任务目标和非目标：要做什么必须写清楚，不能做什么也要写清楚；其次是事实源，必须明确以哪一份文档或定义为准，不能同时存在多个彼此冲突的数据来源，否则 Agent 也会困惑。

这些内容可以转化成不同形式的文档：有些方便人阅读，有些方便 Agent 获取上下文，还有一些适合机器直接检查。不同文档承担的作用不同，也会影响 Agent 的工作效率。

对抗验证也是一样。人做 Code Review 时，本来就会从不同角度检查代码：命名和格式是否规范，是否重复实现了系统中已有的能力，问题定位是否找到了真正的根因，还是只解决了当前的 Bug Fix Case，却没有覆盖其他同类问题。

因此，在 Agent 参与 Review 时，也需要让不同的 Agent 分别关注不同侧重点。

证据层最重要的是可视化、可验证。在现在这种工作范式下，无论让人直接阅读大量代码，还是阅读大量 Markdown 文档，成本都很高。通过 HTML 验证报告以及架构图、流程图等可视化方式，人可以更快地看清测试过程、测试结果和最终结论。

中间过程同样需要被记录。我们现在有些 Agent 任务会连续运行十五到二十个小时。任务结束后，我们会担心它是否还记得最初的目标，执行过程中有没有跑偏。仅靠上下文压缩和模型自身的记忆，很难完全兜住这种长任务，所以通常会借助外部的工具，阶段性持久化它的工作状态。

任务完成以后，我们还会要求 Agent 重新复述：最初让它完成的到底是什么，任务目标是什么，它采用了什么方案，又是怎样达成目标的。每完成一个阶段都做一次这样的回溯，就能比较清楚地判断这一阶段的实现有没有跑偏。

案例一：新项目构建——从第一天把 Harness 内建进研发流程

第一个案例是一个从零建设的 Rust 项目，代码规模超过 40 万行，基本由 Agent 从头参与开发。

项目开始时，我们首先考虑的是怎样建立初始仓库，而这件事也是从设计文档开始的。包括 AGENTS.md 在内的核心文档，首先要明确唯一事实源：哪些文件负责定义设计契约，API 应当以哪份文件为准，都必须说清楚，才能成为 Agent 后续开发时的可靠依据。

在项目级文档之下，每个模块还会有粒度更细的说明。我们不能把一份体量巨大的文档一次性加载进上下文，那样未必能取得理想效果。因此，文档需要分层，让 Agent 根据当前任务读取对应模块的信息。

每次发生变更时，我们还要求同步提交变更文档。从传统软件工程的角度看，这些事情并不新鲜，本来就是日常开发应该完成的工作，只是在实际执行中，人经常会偷懒。

有一个关于程序员的段子：程序员最讨厌别人的代码没有注释，也讨厌给自己的代码写注释。进入 Agent 时代以后，一个好处是 Agent 在这方面通常不会偷懒。只要团队把要求定义清楚，它就能够帮助维护相对完整的文档。

文档还需要与测试用例和代码持续对齐，并在每次变更时通过 CI 检查。只有这样，文档才能真正进入研发闭环，而不是写完以后便失去作用。

这个项目每天的变更很多，基本上每一个 PR，无论大小，都要有相应的变更文档。文档需要说明这次变更的动机和影响。一方面，负责 Code Review 的人可以先通过文档理解变更；另一方面，Agent 后续定位 Bug 时，也可以追溯到当时的变更记录。

项目运行一段时间后，如果出现问题，Agent 可能恰好检索到相关的变更文档，并从中发现当时遗漏的内容，从而更快地定位代码问题。

测试过程也需要可视化。Agent 可以快速生成大量测试，也可以把覆盖率做得很高，但人最终可能并不知道它到底测了什么，也无法判断测试路径是否有效，或者是否使用了大量无效 Mock。

单纯通过 Prompt 要求 Agent “认真测试”并不可靠。我们的做法，是把开发和测试过程做成可视化展示，并在每次发布时生成一套完整的可视化资产。

Reviewer 可以点开具体的测试路径，查看它覆盖了状态机中的哪些状态和跳转。如果一百个测试始终只覆盖两个状态之间的跳转，即使测试数量很多，质量也未必高，这种情况下就需要返工。

测试是否可信，不能只看数量和覆盖率，还要看它实际覆盖了哪些路径。

Code Review 则通过 CI 门禁完成。CI 门禁是项目质量的重要兜底，也是最终的防线。我们把它分为硬门禁和软门禁。

硬门禁通过机器脚本确定性地检查约束。例如，要求提交变更文档却没有提交，脚本可以直接发现并要求补充，这类问题没有必要浪费 Token。

软门禁主要由不同 Agent 执行 Code Review。我们会配置不同模型和 Prompt，让它们从不同侧重点审查变更。

有的 Reviewer 重点检查 Contract，核对变更目标、代码实现和规则是否一致；有的 Reviewer 专门做“减法”，不断追问代码是否多余、能不能简化；还有的 Reviewer 负责检查项目中是否已经存在可以复用的能力。

一个 40 多万行的项目，无论是人还是 Agent，都不可能了解全部代码以后再开始工作。但 Reviewer 可以借助文档和代码检索，发现某条路径是否已经有现成实现。如果重复造轮子，不仅会带来冗余，还可能在系统中造成二义性。

这些不同的 Review 视角，需要在实际暴露问题以后逐步沉淀到门禁中。它们共同构成了新项目中的 Harness：从文档和唯一事实源开始，经过测试证据和多视角 Review，最终形成可验收的研发闭环。

案例二：存量项目改造——先补 Harness，再做仓库升级

第二个案例是一个代码规模超过 60 万行的 C++ 存量项目。从一次大规模重构算起，这个项目已经持续开发了四五年，团队有几十人，期间人员也经历过多次变化，维护成本本身就很高。

一开始，团队并没有正式鼓励大家使用 AI Coding。后来我们发现，其实不需要鼓励，很多人已经在私下使用，因为它确实能够节省时间，至少不用手工输入那么多代码。

但开发者使用 AI 生成代码以后，未必会明确说明这部分代码来自 AI。任务完成速度变快了，提交的代码量也变大了。架构师做 Review 时非常痛苦，但发布日期又卡在那里，很难简单拒绝提交。

一旦审查稍有放松，问题很快就会出现。有一段时间，这个项目的代码缺陷率飙升到了 20% 以上。

我们开始治理这件事时，首先确认了一点：不能退回到禁止使用 AI 的状态。大家已经用上了这个工具，再要求他们不用，基本不现实。即使强调存量项目风险高，也阻止不了开发者继续寻找使用方式。

唯一可行的办法，是让大家光明正大地使用 AI，同时让团队也能够光明正大地约束和拦截它。因此，我们开始对项目进行 AI 友好化改造，把 Harness 的思路应用到存量工程中。

改造完成后的一个月，项目代码缺陷率从 20% 以上降到了个位数，变化非常明显。

问题背后的原因并不复杂。由于团队人员不断变化，新成员很难完整理解这样一个复杂项目，也很难了解项目历史。更麻烦的是，历史文档和代码本身也可能存在错误。新人基于这些信息编写代码，容易出现问题，负责 Review 的人也未必能够识别所有偏差。AI Coding 提高开发速度以后，问题只会暴露得更多、更快。

这种情况在很多老项目中都很典型：事实源不固定，文档分散、缺失或者内容错误；不同文档之间相互矛盾，文档和代码也可能不一致；项目中还存在大量重复实现，而这些“轮子”之间同样可能互相冲突。

所以，改造的第一步不是让 Agent 修改代码，而是让 AI 扫描整个项目。

这个过程大约持续了一到两周。Agent 从项目整体开始，自顶向下进入各个模块和接口，一层层梳理文档、代码和实际行为，找出其中的不一致。

对于已经存在的历史错误，我们不可能立刻全部修改。代码即使有问题，仍然承载着现有业务，不能简单删除或重写。我们能做的是先订正事实，重新编写文档，建立唯一事实源。

以后 Agent 进入项目，无论处理什么需求，都必须先读取这套核心文档。系统再根据任务内容，把它路由到对应的模块文档。

例如，一个任务涉及网络模块，就让 Agent 继续读取网络模块的说明。文档会明确告诉它，旧代码与旧文档在哪些地方存在出入，哪些历史实现虽然暂时保留，但并不是后续开发应该遵循的正确路径。

Agent 可以暂时不修改那些历史错误，但必须知道它们是错误的，也必须知道以后应该沿着哪一条路径开发。

完成文档体系重建以后，我们再把前面提到的 Review 规则和 CI 检查逐步放进门禁。存量项目的 AI 友好化，要先补上 Harness，再让 Agent 进入具体改造。

面对大型存量工程，我们还担心 Agent 一次修改过多代码，把项目影响面扩大。因此，在任务开始之前，团队会先进行功能切片和任务拆分，把边界相对清楚、影响范围比较可控的部分交给 Agent。

最早的试点之一，是 C++20 升级。

这个项目过去经历过从 C++11 到 C++14、再到 C++17 的升级。我记得仅从 C++14 升级到 C++17，就用了大约半年时间。继续升级到 C++20，新的语言特性更多，整体改造也更加复杂。

但这类任务有一个特点：升级过程理论上应该保持语义等价，测试目标和验收标准相对清楚。因此，在完成前面的 AI 友好化改造后，我们选择了一个局部代码模块，让 Agent 按照既定流程进行 C++20 升级和模块化重构。

这次试点取得了不错的效果。局部流程跑通以后，团队才进一步拆分出多个模块和需求，以并发方式推进后续改造。

总结：全流程研发闭环，持续并行

前面两个项目中的 Harness 流程，主要关注研发团队内部的技术闭环：从技术需求开始，到完成技术验收结束。

但在完整的研发流程中，闭环还需要继续向前延伸。

当编码速度显著提高以后，产品需求的表达速度可能会成为新的瓶颈。产品人员可能会说，研发编码这么快，自己写 PRD 的速度已经跟不上了。如果跟不上，同样可以与 AI 协作。

产品人员可以让 AI 帮助澄清和复述需求，检查 PRD 中是否存在歧义，并把原本模糊的表达整理清楚。产品和研发还需要逐步形成共同的语言规范，减少模糊沟通和依赖个人脑补的情况。

从需求澄清、技术选型、方案对比，到编码、测试和最终验收，整个流程都可以采用人与 AI 协作的方式，并在每个阶段产生规范化的产出物。

当所有阶段都有迹可循，同时配合规范化文档和渐进式披露，Agent 在协作过程中就能做到相对可控。之所以说“相对可控”，是因为模型本身的能力和行为仍然可能波动。

我们曾经长期使用某个模型。一段时间内，它倾向于尽可能帮助用户补全没有想到的 Case；但后来有一段时间，它又突然变成尽可能少做。

这类变化有时不容易被 Harness 发现。最终功能看起来可能差不多，但人检查具体实现时，会发现实践质量存在明显差异。

因此，从目前的 AI 协作和 Harness 实践，走向真正自治、稳定的开发体系，还有很多路要走，也需要持续探索。

AI Coding 出现以后，很多人讨论它会不会取代工程师。我的判断恰恰相反：AI Coding 对工程师的要求会越来越高。

模型能力越强，我们对它的期望也越高，就越希望它完成更加复杂的事情。任务越复杂，暴露的问题就越多，对工程师定义目标、识别边界、判断架构和验收结果的能力要求也越高。

人与 AI 的协作还会持续下去。我们真正要解决的，不只是如何让 Agent 写出更多代码，而是如何让它交付的任务能够被约束、被验证、被验收。

AI Coding 提升了代码生产速度，而 Harness 要做的，是让验证速度和验收能力与之匹配。只有形成覆盖需求、开发、测试和交付的完整闭环，AI 的高产能才可能真正转化为稳定的软件工程效率。

39 AI Coding 提速之后，如何补上稳定性「最后一公里」？快手柯南 AI 实践

AI Coding 正在显著提升代码生产效率，但线上告警、根因定位、止损和修复等稳定性环节并未同步提速。更值得警惕的是，缺乏全局上下文的 AI 可能沿着“最小阻力路径”消除表面现象，却留下跨工程、跨系统的稳定性隐患。当 AI 开始规模化生产代码，谁来承接随之增长的线上问题，正成为 AI Native 研发体系必须补上的“最后一公里”。

在 AICon 全球人工智能开发与应用大会（上海站）2026 上，快手主站技术稳定性专家王泽锋分享了“柯南 AI”的工程实践。这次分享的核心并不是简单地“让 Agent 代替人排障”，而是重新设计稳定性研发中的人机分工：确定性的流程交给代码，概率性的推理交给模型；通过 Skill 沉淀专家经验，以源码服务和端侧基建提供有效上下文，再用 Bad Case 驱动系统持续进化。

目前，柯南 AI 在快手内部大前端研发中的用户渗透率已接近 60%，根因分析结果的完整采纳率稳定在 50% 左右。在一个只有系统堆栈的鸿蒙 C++ Crash 案例中，它通过寄存器、业务日志和源码构建证据链，约 10 分钟便定位到内部基础组件触发的纯系统堆栈 Use-After-Free 问题，并帮助团队找到止损开关。围绕这一案例，王泽锋进一步拆解了柯南 AI 的五层架构，以及稳定性专家如何从“前线救火员”转变为“消防系统设计师”。

AI Coding 提速之后，稳定性成为“最后一公里”

AI 浪潮给稳定性带来了什么影响？

如今，Cursor、Claude Code、Codex 等 AI Coding 工具已成为行业主流。上游研发吞吐显著提升，需求到代码的转化成本大幅降低。与之相比，线上告警、根因定位、止损决策、修复回归和经验沉淀等下游处置链路，几乎没有得到同等加速。

当代码生产与稳定性处置长期速率不对等，线上 Case 的数量、严重程度和处置时延都可能全面劣化。更棘手的是，AI 不仅放大研发吞吐，也可能制造新的稳定性问题。由于缺乏全局上下文，AI 往往沿着“最小阻力路径”让问题现象消失，但现象消失不等于问题被真正解决。这就是 AI 普遍存在的局部最优陷阱。

快手内部曾遇到过这样一个案例。

在 Android 版本发布前的灰度阶段，我们发现 APK 包体突然增加了 6 MB。紧急排查后发现，问题来自一个内部 SDK：开发者通过 AI 生成了一段 ProGuard 配置，其中包含 -dontoptimize，并将其写入 consumerProguardFiles。

从 SDK 自身看，这段配置可以让工程正常运行。但 consumerProguardFiles 会随 AAR 传递到主工程，在构建时与 R8 配置合并，最终关闭主工程的 R8 全局优化，导致 DEX 体积膨胀，APK 增加 6 MB。

从 AI 的视角看，这个结果有其“合理性”：它只看到了 SDK 能够运行的局部，却没有意识到配置会跨越工程边界。

SDD、Coding Harness 以及 Coding、Review 阶段的前置约束，可以提高代码生成质量，拦截一部分问题，但不可能消灭所有稳定性风险。

大前端领域有一个显著特点：线上状态空间极其庞大。以机型碎片化最严重的 Android 系统为例，线上存在超过 100 种 OEM ROM、1000 多个适配机型。对于快手这样的强运营 App，一天内由 A/B 实验、灰度和运营活动带来的变更可能超过 1 万次。用户行为路径更是千人千面，无法穷举。

没有任何测试矩阵能够在线下覆盖所有组合。从更高层面看，软件稳定性本身就是一个“不完备性证明”问题：我们无法证明所有场景都绝对稳定，只能不断加深防御纵深。

线上真实现场永远是稳定性的核心战场。

研发吞吐被 AI 拉快，稳定性处置没有跟上；AI 会陷入局部最优，而前置拦截又无法消灭所有问题。这些因素共同指向一个结论：**线上稳定性处置，是完整落地 AI Native 的最后一公里。**这也是我们建设柯南 AI 的出发点——聚焦稳定性领域，“用 AI 打败 AI”。

柯南 AI：嵌入工作流的稳定性数字同事

“柯南”这个名字来自《名侦探柯南》——“真相只有一个”。我们的愿景，是让柯南 AI 成为所有 Bug 的最终归宿。

完整的稳定性生命周期通常包括拦截、监控、排障和止损。现阶段，柯南 AI 主要聚焦排障与止损，也就是问题处置环节，覆盖四类场景：

• 报警处置，包括问题解释、影响面判断和 SOP 执行；
• 根因分析，包括线索发现、假设提出和证据链构建；
• 修复建议，包括修复方向、风险和验证方式；
• 治理初检，包括优先级判断与问题分发。

我们选择问题处置环节，首先是因为它最消耗业务研发时间，建设 ROI 较高；其次，这些任务需要聚合信息并进行多步推理，适合 AI；同时，这也是稳定性专家经验能够发挥较高杠杆的地方。

在产品形态上，我们有一条原则：不额外创造孤立的交互方式，而是把柯南 AI 嵌入开发者已有的工作流。

目前主要有三种产品形态。

第一种是 IM 机器人，服务于报警处置、指标巡检和问题分发。这些任务原本就需要多人协作，通常发生在 IM 群聊中，机器人可以直接进入原有协作场景。

第二种是监控平台侧边栏。研发打开崩溃详情页后，可以拉起柯南 AI。系统会自动携带当前崩溃的上下文，触发根因分析。

第三种是 CLI。它与侧边栏都覆盖根因分析和修复建议，但主要解决监控平台信息不足的问题。有些问题需要连接手机，拉取设备上的 so 文件或其他现场信息。此时，研发可以将问题上下文从监控平台流转到 CLI，继续本地排查。

目前，柯南 AI 在内部大前端研发中的用户渗透率接近 60%，根因分析结果的完整采纳率稳定在 50% 左右。

柯南 AI 的五层工程架构

柯南 AI 的整体架构分为五层：最上层是应用层，对应 IM 机器人、监控平台侧边栏和 CLI；下面依次是 Agent 编排层、Agent Harness 层、数据服务层和端侧基建层。另有一套可观测与反馈迭代机制纵向贯穿整个系统。

编排层：确定性的归代码，概率性的归模型

Agent 编排层主要回答一个问题：什么任务应该由什么形态承载？

我们的核心原则是：确定性的归代码，概率性的归模型。

对于流程清晰、规则明确、答案相对唯一的确定性问题，我们使用代码实现；只有涉及理解、推理和判断的部分，才让模型介入。把大模型放在它擅长的位置，才能兼顾效果稳定与成本可控。

报警处置是柯南 AI 的重要场景。在 AI 时代之前，快手已基于大量经验沉淀出一套完整 SOP：从报警发生、拉群，到多人分工排查，再到止损和复盘，包含一套严肃而复杂的协作流程。

这样的流程不适合完全交给 Agent Loop 驱动。Agent 可能遗漏步骤，也可能调用错误工具，这在报警处置中无法接受。因此，我们通过用代码复刻人工 SOP，只在部分子环节引入模型。

进入概率性任务后，我们还有一条原则：单次 LLM 请求能够解决的问题，就不使用 Agent。

任何任务都使用 Agent，是一种过度工程化。Agent Loop 每增加一轮，就会增加一次 LLM 请求，带来额外时延和 Token 消耗；Tool Call 可能失败，Agent 的自主决策也可能跑偏。如果任务确实需要长链推理，这些代价值得付出。但如果一次 LLM 请求已经能够解决问题，强行使用 Agent 反而可能成为负优化。

报警处置中的“快速分析”就是一个例子。它的目标是汇总各类维度数据，提炼关键线索。我们先通过代码聚合数据，再将上下文一次性放入 Prompt，要求模型按预设的结构化模板输出结论。

这种方式最大的优势是快。从获取 API 数据到 LLM 返回结果，整体耗时可以稳定控制在 1 分钟以内。

例如，WWDC 之后 iOS 27 开始向用户推送，我们曾遇到一个小规模堆栈报警。快速分析发现，问题百分之百集中在 iOS 27，很快便将范围收敛到某个内部工具在新系统上的兼容性问题。

真正适合 Agent 的场景是根因分析。一个复杂问题可能需要结合堆栈、源码、代码变更、聚合特征和历史相似 Case 才能找到根因。整个过程横跨多个数据源，涉及多次 Tool Call，通常也不存在固定的线性推理流程。这类任务需要长链推理、跨工具调用和自主编排能力，也需要动态扩展上下文、按需加载 Skill。只有遇到某类问题时，才加载相应知识，可以避免上下文一次性膨胀。

因此，我们在编排层组合使用三种形态：确定流程使用 Workflow，简单概率性任务使用单次 LLM 请求，复杂非线性推理任务使用 Agent。

Agent Harness：基于成熟底座，用 Skill 承载专家经验

在 Agent Harness 层，我们没有从头搭建通用框架，而是直接使用 Claude Agent SDK（前期原型探索，经历过从 AutoGen 框架编排到基于 OpenAI Agent SDK 的自研 Workflow 框架，再到最终敲定使用 Claude Agent SDK）。这一选择有三个好处。

首先是工程红利，可以直接继承在生产环境中经过打磨的上下文管理、工具使用等 Agent Harness 能力；其次是迭代同步。SDK 会随 Claude 系列产品持续演进，我们可以较快使用新的 Harness 能力；最后是适配深度。Claude Agent SDK 对 Claude 模型有较好的适配，国内主流开源模型也可以通过兼容协议接入。

不过，Claude Agent SDK 面向通用 Coding 环境，并不完全适合稳定性根因分析，因此我们做了两方面的轻量化定制。

一方面，我们围绕领域诉求精简 System Prompt。通用 Agent 的 System Prompt 中存在不少与稳定性分析无关的内容。我们剥离通用 Coding 约束、Auto Memory 机制和通用 Skill 清单等噪声，同时注入稳定性领域的硬规则，例如明确区分推测与确定性结论、标注结论置信度，以及禁止跨问题类型进行无关联想。

另一方面，我们精简 Tool 并设置 Permission 沙箱，确保 Agent 即使失控，影响半径也能被控制。对于计划、工作树等不需要的通用工具，我们直接关闭。对于确实需要的 Read、Write、Edit 等 Bash 类工具，则将访问路径锁定在当前工作目录，即 CWD。绝对路径一旦越界，系统会直接拒绝。

在外围框架之外，我们投入最多的是用 Skill 承接稳定性专家经验。

Skill 具备渐进式披露和按需加载能力，可以根据问题类型，只为 Agent 注入当前需要的知识。目前，我们在客户端领域已经建设了 30 多个 Skill，正文与 Reference 文档接近 2 万行。如此规模的知识不可能一次性放入上下文。

Skill 对知识迭代也很友好。它本质上是带有轻量格式约束的 Markdown 文档。维护者不需要理解 Agent Runtime，也不一定需要写代码，只要能把专业知识整理成清晰文档，就可以参与建设。这样，专家经验的维护不再局限于 Agent 工程团队。

在 Skill 的组织方式上，我们遵循两个原则。第一，Skill 不与 Agent 工程耦合。所有 Skill 通过独立 Git 仓库维护，可以独立发布、灰度和回滚；第二，按照异常退出类型划分 Skill 边界。例如 Android Java Crash、iOS Crash、Android Native Crash 都对应独立的 Skill。虽然不同分析流程存在共性，但我们的判断是：可以接受适度的重复建设，但必须避免跨端、跨异常类型的上下文干扰。

对于单个 Skill，最重要的内容首先是私域知识注入。

一种典型情况是，某些字段的实际语义已经与最初上报时不同，本质上是在偿还历史技术债。

例如，在较低版本的 Android 系统中，每个进程能够使用的文件描述符数量存在较低上限。一旦 FD 数量超过阈值，进程就可能崩溃。为了快速定界，历史上的 APM SDK 会在崩溃时采集 FD 数量，只要超过阈值，就将问题标记为 FD OOM。但这套规则在较高版本的 Android 系统中已经失效。如果 Agent 在高版本系统上看到这个标签，仍按旧规则分析，就可能非常自信地给出错误结论。对此，我们会在 Skill 中明确写成禁止行为。

另一类私域知识来自内部框架和 SDK，这些内容从未出现在模型训练语料中，只能由团队主动注入。

例如，Ekko 是内部用于崩溃兜底的安全气垫 SDK。在部分端上，它需要在崩溃链路中执行 Hook，因此某些堆栈会出现 Ekko 栈帧，但这些栈帧与根因没有关系。如果不加约束，Agent 看到 Ekko 栈帧后，可能沿着 Hook 逻辑继续追踪，导致分析方向跑偏。因此，我们会在 Skill 中明确说明 Ekko 栈帧的语义和排除规则。

除了私域知识，Skill 的另一个重要组成部分是根因分析 SOP。

以鸿蒙 AppFreeze 为例，这类问题通常意味着主线程长时间卡顿甚至卡死。分析时，我们会先获取卡死前的多次采样堆栈，比较堆栈是否一致，从而判断主线程是真的阻塞，还是因过于繁忙、无法及时处理窗口消息而被识别为 Freeze。

如果确认主线程确实阻塞，并正在等待某把锁，下一步就要查看全线程堆栈，判断哪个线程持有这把锁并卡住了主线程。

类似决策树会被完整写入 Skill。我们的鸿蒙 AppFreeze 根因分析 Skill 也参考了华为系统 DFX 团队提供的开源版本，其中通用的主线程根因决策逻辑就来自该版本。

另一个例子是 Android Native Crash 和鸿蒙 C++ Crash 的信号路由。

如果问题由 SIGABRT 触发，根因更可能已直接写在 Abort Message 中。典型情况是 Android 的 Java Pending Exception 导致进程 Abort。对于这类问题，Skill 会要求 Agent 优先查看 Abort Message，而不是一开始就进入复杂的内存分析。

只有遇到 SIGSEGV 这类段错误，才需要继续进行反汇编、寄存器分析等深入排查。

实践表明，这类核心决策逻辑不仅能提高效果，还能减少耗时和 Token 消耗。不过，这部分知识相对偏向公域，可能只是当前模型尚未很好地内化。随着模型升级，未来某些通用知识未必还需要通过 Skill 注入。

目前，Agent Harness 层仍有两个主要瓶颈。

首先是思考深度不足。例如遇到 NPE，模型经常只能指出“这里为空”，却无法沿数据流继续追踪，找出什么数据经过什么路径导致对象为空。在信息缺失时，模型还容易产生幻觉，补出一个似是而非的结论。

短中期内，我们一方面会通过 Skill 和 System Prompt 强化约束，另一方面进行问题分级路由：提前识别问题难度，将复杂问题分配给能力更强的模型。长期来看，则需要探索树形搜索等 Agent 编排方式，让系统围绕多个根因假设并行收集证据。当然，这也会增加 Token 消耗。

其次是修复效果明显落后于排障效果。一方面，Agent 缺少历史修复经验，不知道相似问题过去如何修复；另一方面，大量业务“暗知识”只存在于人脑中，例如某块代码能不能改、怎样修改才符合业务规范。这些信息既不在堆栈里，也不在文档中。

我们正在探索通过 Memory 体系承载历史经验和业务暗知识，但前提是业务知识必须持续显性化。没有被表达和沉淀的知识，就无法成为 Agent 可以使用的上下文。

数据服务与端侧基建：上下文决定 Agent 的效果上限

源码是崩溃分析中仅次于堆栈的重要信息。为了让 Agent 高效消费源码，我们建设了独立的源码服务，而不是每次分析时重新克隆代码仓库。原因有两个。

第一个是解决“仓库找不到”的问题。一个崩溃堆栈可能横跨 5 到 10 个代码仓库，崩溃模块名与仓库名往往并不一致。一个包名对应哪个仓库、分支和 Commit，仅靠堆栈通常无法判断。源码服务可以提前完成仓库聚合与索引。

第二个是解决拉取与检索效率问题。大型客户端主仓规模庞大，一次 git clone 至少需要几十秒，甚至达到分钟级。如果每次分析都重新拉取代码，这种时延无法接受。源码服务预先聚合所有仓库，让搜索过程接近本地 grep 的速度。

数据准备好后，还要解决如何暴露给 Agent。

我们的做法是，把原本面向人的 GUI 数据接口，重新包装为面向 Agent 的 Bash 接口。Agent 可以通过 git grep、git blame 等命令，在源码仓库中自由探索。模型训练语料中包含大量 Bash 操作，因此天然熟悉相关语义，也不需要为每种查询重新定义 API Spec。

Bash 接口给了 Agent 足够的灵活性，但也带来安全风险。为此，源码在服务容器中以只读方式挂载，同时配合完整命令日志和执行超时，确保过程可控、可追溯。

这一层的原则可以概括为：提供 Agent 友好的数据接口，让它自由探索，但不能允许它越界。

源码服务还有两个演进方向。

第一个是从关键词检索走向语义检索。当前源码服务本质上仍是类似 grep 的全文搜索，但这种方式在部分问题上表现不够好。

还是以 NPE 为例，我们不仅要知道问题崩在哪一行，还需要跨函数、跨文件追踪对象或变量的生命周期。遇到跨语言问题时，还要理解不同语言之间的桥接关系。grep 或许能完成其中一部分工作，但很难成为最优方案。

参考研发人员使用 IDE 排查问题的经验，语义检索是一个更可靠的方向。因此，我们正在调研 LSP、Code Graph 等方案。

第二个方向是从单体架构向分布式架构演进。目前，源码服务每天已经承载数万次调用，逐渐触及单体架构的扩展性瓶颈。随着源码覆盖率和接入场景继续增长，系统必须通过分布式架构满足并发检索需求。

再向下是端侧基建层。上下文才真正决定 Agent 的效果上限。Agent 无法凭空创造信息，更无法凭空创造有价值的信息。

在稳定性领域，端侧基建就像 Agent 这座冰山位于水面之下的地基。它决定 Agent 能看到什么现场，也决定 Agent 能分析到什么深度。我们目前探索的一个方向，是 Android、iOS、鸿蒙三端的 Core Dump。

对于某些疑难问题，Core Dump 非常有用，甚至可能是唯一解。例如 Android ART 虚拟机中 JIT 机器码的踩内存问题，其 PC 可能直接落在 JIT Code Cache 内存段上。即使有 Tombstone 文件，也只会 Dump 出 PC 附近数百字节的内存，往往不足以覆盖 JIT 机器码的完整内容。

只有 Core Dump 能够完整保存整个进程的内存快照，为分析提供足够信息。

过去我们没有大规模建设这项能力，核心原因不是采集端难以实现，而是消费成本过高。Core 文件是纯二进制格式，通常几百 MB 起步，结构复杂。只有少数资深稳定性专家能够结合 LLDB、GDB 等工具，在数小时甚至数天内挖掘出有效信息，整体 ROI 不高。

AI 改变了这套 ROI 公式。过去难以消费的信息，现在可以交给 Agent 挖掘。Agent 可以自动反汇编关键内存区域，并关联源码、寄存器和其他现场信息。Core Dump 的消费能力由过去“只有少数专家掌握”，转变为“研发人员可以借助 Agent 使用”。

这带来了端侧基建方向的一次认知升级：在 AI 时代，端侧基建需要从“为人优化”，转变为“为 Agent 优化”。

反馈迭代：用 Bad Case 驱动长期效果提升

围绕可观测、可评测和可运营的目标，我们建立了一套从链路层、指标层到运营层的三层观测体系，覆盖从单次调用到整体运营的完整链路。

链路层用于还原一次 Agent 调用的全部细节，包括思考过程、工具调用和行为轨迹，是分析具体问题、提升效果的重要工具；指标层服务于成本看清和性能优化，关注耗时、Token 消耗和调用成功率等全局指标；运营层通过数据大屏，从业务视角观察产品健康度和使用情况。

在此基础上，我们通过 Bad Case 驱动持续优化。这里要解决一个矛盾：AI 不知道自己不知道什么，因此容易产生幻觉；人也未必能立即意识到，自己掌握的哪些知识还没有告诉 AI。

迭代过程主要分为两步。

第一步是 Case 管理。我们基于观测数据搭建 Case 标注平台，并制定统一的采纳率标准。团队会筛选有效问题、进行用户回访，再结合专业经验对回访结果进行二次确认。经典 Case 会进入评测集，对应缺陷则转化为优化项。

第二步是 Case 总结。我们通过固定例会，对采纳率和细粒度 Case 进行 Review，持续拉齐采纳标准，共识优化项优先级并推动落地。

架构、Skill、源码服务和端侧基建都很重要，但它们发挥作用的前提，是团队能够长期落实反馈迭代机制。

一个纯系统堆栈问题，柯南 AI 如何在 10 分钟内完成定位

这是一个鸿蒙 C++ Crash 报警。崩溃信号是 SIGSEGV，崩溃地址很大，属于典型的踩内存问题。继续查看堆栈可以发现，每个栈帧都来自系统 so，是一个纯系统堆栈。

过去，这类问题通常只能由平台型稳定性团队介入。柯南 AI 接入工作流后，报警发生时会先由 IM 机器人串联处置流程。

从开始分析到定位问题，柯南 AI 大约用了 10 分钟。团队随后根据分析结果讨论止损方案，最终通过关闭一个开关完成止损。柯南 AI 给出的底层根因是：系统库 libuv 中某个 Async Handle 发生了 Use-After-Free。但对于止损优先的稳定性处置来说，仅知道底层内存错误还不够。我们更关心哪个业务、哪个动作触发了提前释放。

柯南 AI 随后给出触发链路：某个内部基础组件加载资源文件失败后，该组件内部执行了一次销毁动作，最终引发崩溃。这个信息帮助我们把问题收敛到内部特定业务，并在其中找到止损开关。

柯南 AI 整个推理过程分为几个阶段。

首先，根据 Skill 中的信号路由规则，SIGSEGV 应进入内存分析流程。柯南 AI 通过寄存器分析，判断问题大概率属于 Use-After-Free。随后，它分析业务日志中的共性特征，将范围收敛到某个内部基础组件，并发现关键动作与线程销毁有关。在这个过程中，得益于注入的私域知识，Agent 正确排除了部分日志噪声，没有被无关信息带偏。最后，它根据日志线索定位源码，将寄存器、日志与源码三部分证据组合起来，形成自洽的证据链，并给出高置信度结论。

这个问题的分析过程并不简单。过去，它需要稳定性专家操作多种工具、反复交叉验证。现在，中等难度的问题可以优先交给柯南 AI，研发人员再根据分析结果完成决策和止损。

综合整个工程实践，我们沉淀出五点关键认识：

1. 确定性的归代码，概率性的归模型。 组合使用 Workflow、单次 LLM 请求和 Agent，避免过度 AI 化，才能保证效果稳定与成本可控。
2. Agent Harness 的技术选型应当轻量化、领域化。 基于成熟可靠的 Agent SDK，通过 Skill 承载专家经验，不必重复建设通用底座。
3. 数据服务的关键是提供 Agent 友好的接口。 Bash 是一种有效形态，因为大模型天然熟悉其语义，但必须配套权限与安全边界。
4. 上下文决定 Agent 的效果上限。 端侧基建决定 Agent 能看到什么，也决定它能够分析到什么程度。
5. 反馈迭代决定 Agent 的长期表现。 只有持续运行 Bad Case 驱动的闭环，才能不断提高系统效果。

从“前线救火员”到“消防系统设计师”

从人的角色变化来看，稳定性专家正在从亲自处理每个问题，升级为建设一套能够处理问题的系统。这既是机遇，也是挑战。

排障原本就是一类推理密集型任务。进入 AI 时代后，稳定性专家的经验有机会被规模化放大。专家的工作开始从亲自排查每个问题，转变为沉淀 Skill、共建 Context，并驱动 AI 完成一线工作。

从角色上看，稳定性专家正在从前线救火员，转变为消防系统设计师。

与此同时，Context 才是我们真正的壁垒，也是享受模型升级红利的前提。模型会持续变强，但如果没有 Skill、端侧基建、源码、现场数据和反馈机制打底，模型仍然无法在垂直稳定性领域跑通。

未来，我们会继续推动 Agent 工程深化与上下文工程复利。

在 Agent 工程侧，需要探索 Loop Verify、多路径或多 Agent 编排机制，以及 Memory 体系，突破长尾问题的采纳率瓶颈。

在上下文侧，需要深化端侧基建，建设 Core Dump 等能够提供更完整现场的能力，并持续沉淀私域 SOP 和业务知识，确保系统能够真正获得模型升级带来的收益。

在这些能力的基础上，柯南 AI 还要从问题处置走向治理优化，反哺稳定性体系建设：让专家投入更系统性的工作，让一线研发完成更深入的优化，最终放大人的影响半径。

现阶段的柯南 AI 不是终点，而是我们在稳定性领域“用 AI 打败 AI”的新阶段起点。

嘉宾介绍：

**王泽锋，**快手大前端稳定性方向技术专家。2023 年加入快手，先后参与 Android & 鸿蒙稳定性方向监控报警、排障工具、止损工具等多个领域的建设，目前主要聚焦探索 AI + 稳定性方向。

40 AI Coding 贡献率超 90％，需求交付却只快了 10％：菜鸟如何用 Agent 托管端到端交付？

在 2026 年 AICon 全球人工智能开发与应用大会上海站上，菜鸟网络研发总监郭凤钊分享了菜鸟在 AI 研发效能领域的实践。

过去半年多，菜鸟内部 AI Coding 贡献率从约 10% 提升至 90% 以上，但编码自动化并未带来同等幅度的需求交付提速。为此，菜鸟开始将探索范围从 Vibe Coding 扩展到需求端到端托管交付，并尝试用通用 Agent、Plugin、Playbook 和云端沙箱构建企业级交付体系。

本次分享涵盖菜鸟 AI Coding 的推广过程、需求托管交付 Agent 的技术方案、产品规模化推广的思考，以及 AI 研发效能的度量方法。

从 10% 到 90%：AI Coding 的普及只是起点

菜鸟大规模推广 AI Coding，大约始于 2025 年 10 月。当时，大多数开发者并不相信 AI Coding 能够真正处理企业内部的工程问题。很多人的判断是：AI 可以完成从 0 到 1 的新项目，但企业内部面对的是大量存量代码，其中不乏历史包袱沉重、结构复杂的系统，AI 是否还能胜任，需要打一个问号。

因此，早期真正愿意研究 Prompt、Coding Rules 和各种最佳实践的，只是少数对 AI Coding 有热情的开发者。更多人尝试几次，发现效果不理想，便放弃了。当时业界已经出现了一些实践，例如通过 Prompt 和 Rules 约束代码生成、让 AI 遵循 TDD、在编码前先生成 Plan，以及后来逐渐演进出的 SDD 等模式，但尚未形成广泛共识。

当时，菜鸟的 AI Coding 贡献率约为 10%。我们设定的目标是：半年后达到 20%，挑战 50%。这里所说的 AI Coding 贡献率，是指提交到代码仓库中的 AI 生成代码行数，占整体提交代码行数的比例。半年多以后，这一指标已经超过 90%，部分团队接近 100%。

**从约 10% 到 90% 以上，实际增长速度远超预期。**回顾这一过程，我认为主要有三个因素发挥了作用。

第一，SOTA 模型的能力持续提升。从 Opus 4.5、Sonnet 4.5 开始，模型版本不断迭代，基础能力的进步直接抬高了 AI Coding 的上限。

第二，Coding Agent 快速发展。从早期工具到 Cursor、Claude Code、Codex 等产品，Coding Agent 进入激烈竞争阶段，开发者可以把更多真实任务交给 AI，而不再只是生成代码片段。

第三，是企业内部的推广策略。菜鸟主要做了四件事：

1. 找到高度认可 AI Coding、愿意持续探索的开发者，由他们担任 AI 布道师，研究并推广最佳实践。
2. 引入市场上成熟的 Coding Agent。菜鸟内部曾有一个约 10 人的团队开发 Copilot，但市场演进太快，小团队很难与专业产品公司竞争，因此后来选择引入市场化工具。
3. 对团队和个人维度的 AI Coding 贡献率进行度量和公开展示。
4. 与安全团队联合，识别并防范 AI Coding 带来的代码与数据安全风险。

在这些因素共同作用下，菜鸟的 AI Coding 贡献率在 2026 年二三月达到 50%，随后继续上升，平均值超过 90%。但新的问题很快出现：AI Coding 贡献率大幅提高，并不意味着需求交付周期会等比例缩短。

从由『人』主导转变为由『Agent』主导

我们比较了有 AI 参与和没有 AI 参与的需求，发现二者的需求变更周期只相差约 10%。相对于 90% 以上的 AI Coding 贡献率，这个结果显然不够理想。

背后主要有三个原因。

首先，编码只是需求交付链路中的一个环节。需求从澄清开始，还要经历技术方案设计、测试用例生成、代码编写、编译、测试和部署等阶段。即使编码实现 100% 自动化，它在整体交付周期中占用的时间可能也只有 30% 左右。

其次，编码之外的许多步骤尚未被 AI 托管，原有研发系统和流程对 Agent 也不够友好，无法像 Vibe Coding 一样迅速实现自动化。

第三，阶段之间仍然依赖人来推动。一个阶段完成后，需要工程师确认结果、切换工具并发起下一步。如果工程师正在处理其他任务，整个流程就会停下来。

只要流程仍由人主导，人的注意力和时间就是端到端交付的瓶颈。

基于这一判断，我们开始探索需求的端到端托管交付：从需求澄清开始，一直执行到代码部署至预发环境，由 Agent 主导流程，工程师只在必要节点参与确认。

首先要解决的是运行环境问题：托管交付 Agent 应该运行在本地、普通云端环境，还是云端沙箱？

本地环境符合开发者习惯，但云端沙箱有两个明显优势。一是可以提供 7×24 小时的运行环境，不会因开发者关闭电脑而中断任务；二是更有利于企业经验共享。如果最佳实践只存在于某个人的头脑和电脑里，其他团队很难复用。最终，我们选择在云端沙箱中构建托管交付的运行环境。

接下来，是如何构建托管交付 Agent。

长程任务的关键，不只是把 Skill 串起来

在企业内部，我们看到过四类常见方案。

第一类是使用 Workflow，把需求澄清、技术方案生成、测试用例生成和代码生成等节点编排起来。问题在于，需求交付流程很长。如果将所有节点都写进 Workflow，流程很快就会变得难以维护，也缺少灵活性。

第二类是从头定制一套托管交付 Agent。菜鸟在 2025 年 4 月也曾启动过类似项目，使用 Spring AI 开发专用 Agent，但投入成本很高。企业内部不同团队的研发流程并不完全一致，兼容这些差异会进一步增加开发和维护成本。同时，AI Coding 的模式和最佳实践迭代很快，自研系统很难长期保持先进性。

第三类是把各个研发步骤做成 Skill，再由工程师在本地逐一调用。例如，将编写单元测试封装成一个 Skill，完成后再人工触发下一个 Skill。这提高了单个步骤的效率，却没有改变人作为流程瓶颈的问题。

第四类是用一个 Prompt 或 Skill 编排其他所有 Skill。简单场景下，这种方式可以工作，但面对复杂的长程任务时，很容易触碰上下文窗口的边界。即使模型提供了约 100 万 Token 的上下文窗口，真正可用于任务的信息空间也没有看上去那么充裕。Coding Agent 的 System Prompt、历史会话、工具定义、工具调用结果以及读取的文件内容，都会占用上下文。

随着执行轮次增加，任务可能遭遇三类问题。

第一是上下文腐烂，即 Context Rot。上下文中混入大量无关信息后，模型对关键信息的关注能力会明显下降。

第二是上下文耗尽。Anthropic 曾举过一个例子：如果直接要求基于 Claude Code SDK 完成一个完整的 Claude Code 官方网站，任务可能执行到一半就耗尽上下文。即使进行压缩，留下的现场也未必足以支持下一个 Agent 可靠接手。

第三是“上下文焦虑”。当模型接近上下文上限时，可能提前宣告任务完成。开发者有时会看到模型声称“已经完整实现”，但检查代码后，却发现核心功能并没有完成。

因此，处理长程任务时，需要先拆解功能清单，再增量推进：每次只执行一个步骤，完成后检查真实产物，不能只相信模型反馈。

通用 Agent 通常会通过新建会话、压缩上下文、使用 Subagent 隔离上下文、回退或继续执行等方式管理上下文。仅靠 Skill 无法解决这些问题，因为 Skill 本身就运行在上下文中，无法从外部管理自己的上下文。

用 Plugin 管理上下文，用 Playbook 描述企业流程

菜鸟的方案是使用 Plugin。

Plugin 能够承载 Skill、Subagent、Hooks、MCP 和 CLI 等组件，并提供版本管理和分发能力。从上下文管理的视角看，这些组件对应着不同的管理方式：

• Skill 用于渐进式加载知识和操作方法；
• Subagent 创建独立上下文，在内部闭环执行任务，只把结果返回给主 Agent；
• Hooks 在特定事件前后确定性地执行脚本，避免模型因上下文过长而遗忘必须执行的操作；
• CLI 可以通过 --help 等方式逐步发现命令，无须在任务开始时加载所有命令定义。

我们也观察到，CLI 正在替代一部分原本使用 MCP 的场景，原因之一正是它更节省上下文。

在菜鸟的方案中，企业研发任务会被封装成 Skill，再与 Subagent、Hooks 等组件一起放进 Plugin。但 Claude Code 等通用 Agent 并不了解企业内部如何完成一次需求交付，也不知道各步骤之间的关系。

因此，我们又引入了 Playbook，用自然语言描述企业内部的需求交付流程。例如：

• Task 1：需求澄清；
• Task 2：技术方案生成；
• Task 3：测试用例生成；
• Task 4：代码实现及后续流程。

Playbook 会通过 Skill 转换成 todo.json，再由 Executor 循环执行。整个流程运行在云端沙箱中，底层由 Claude Code 等通用 Agent 提供 Harness。此时，它不只承担编码任务，还可以完成需求澄清、技术方案生成和部署。

菜鸟的整体方案可以概括为：通用 Agent 提供 Harness，Plugin 承载能力，Playbook 描述流程，todo.json 保证长程任务的确定性执行。

不同业务团队可以维护自己的 Skill 和 Playbook，并将其打包到 Plugin 中。平台由此能够按照各业务团队定义的流程执行任务，不必在平台层硬编码所有差异。

为什么选择 todo.json，而不是 todo.md

Manus 等 Agent 的早期设计中，会使用 todo.md 管理长程任务：先生成任务列表，每完成一项就划掉一项。Playbook 在一定程度上承担了类似作用，但企业需求交付的状态更加复杂。例如，在生成技术方案前，Agent 必须检查需求澄清文档是否已经生成。如果前置产物不存在，就应该返回需求澄清阶段，而不是继续执行。

选择 todo.json，首先是因为 Markdown 容易被模型直接改写。Agent 可能凭空增加任务，也可能删除原有任务。其次，Markdown 待办列表通常只能区分“完成”和“未完成”，很难准确描述 Pending、In Progress、Skipped、Failed 等状态。

JSON 能够提供更强的结构化约束。我们规定 Agent 每次只能选择序号最小的未完成任务，只能修改任务状态、开始时间和结束时间，不能修改其他字段，更不能增加或删除任务。

执行过程大致如下：

1. 从 todo.json 中定位序号最小的未完成任务；
2. 检查前置任务和必要产物是否已经完成；
3. 将当前任务标记为 In Progress；
4. 调用对应的 Skill 或 Subagent；
5. 检查任务输出是否真实存在并满足条件；
6. 更新任务状态，继续执行下一项。

代码编译和部署适合放进 Subagent，因为主 Agent 不关心中间输出，只需要知道任务是否成功，以及失败原因。其他需要主流程持续使用上下文的任务，则可以通过 Skill 执行。

在需求澄清或技术方案生成阶段，流程还会进入 Waiting for Human 状态，通过 AskUserQuestion 请求工程师确认。确认后，Agent 继续执行后续步骤，形成一个持续运行的 Agent Loop，直到最后一个任务结束。

随着模型能力继续提升，这层 Harness 未来可能进一步简化。届时，也许只需要使用 Markdown 描述流程，模型就能可靠执行。但在当前阶段，结构化状态和确定性约束仍然不可或缺。

用户在哪里，托管交付 Agent 就应该在哪里

在产品形态上，我们坚持一个核心理念：**用户在哪里，托管交付 Agent 就应该在哪里。**菜鸟没有要求用户进入独立的 Agent 平台，而是把能力嵌入现有需求管理系统。

界面由三个区域组成：左侧是 Agent 控制和对话区域，中间是人工 Review 区域，右侧展示执行进展。

过去由工程师或产品经理编写的 PRD，现在可以由 Agent 生成，再由人在中间区域 Review。交互方式也尽量避免要求用户编写复杂 Prompt，而是参考 Superpowers 的 Brainstorming Skill，通过 A、B、C 选择题引导用户补充信息。

需求交付并不总是线性流程。有时任务已经部署到预发环境，团队才发现遗漏功能，或者实现不符合预期，需要回到需求澄清或技术方案设计阶段。因此，我们引入了 Round 的概念，允许一次需求经历多轮澄清和执行，并在不同阶段之间回退。

所有中间产物都会被持久化。Hooks 会监听 todo.json 的变化，一旦检测到新的中间产物，便调用脚本将其写入数据库。用户无须登录云端沙箱，就能在需求管理界面查看执行进展和产物。

云端沙箱也降低了使用门槛。任务启动时，系统会初始化沙箱并克隆用户选择的代码仓库。用户不需要在本地安装 JDK、Maven 或 Claude Code，也不需要准备开发环境。

菜鸟的需求托管交付能力于 2026 年 5 月上线。上线后的最近 30 天内，平台已经交付 100 多个需求。数量还不算大，但已经验证了这条路径能够走通。

一个有意思的现象是，PMO、产品经理和技术运营等非技术岗位，也开始通过这一平台交付生产环境代码。这些代码主要面向内部提效工具。过去，他们需要等待研发排期；现在，一些影响范围有限、失败成本可控的内部需求，可以自行完成交付。

如何更大范围推广托管交付

完成 Demo 之后，我们面临的新挑战是如何扩大托管交付的使用范围。

平台团队很容易从“还应该增加什么能力”的角度思考产品，但平台具备某项能力，并不等于用户需要它。

托管交付早期瞄准的是验证成本较低、一个人能够闭环的小需求。这类需求相对简单，可以快速暴露流程问题，适合验证技术方案。但真正推广时，用户会问：“为什么我要使用云端托管交付，而不是直接在本地使用 Claude Code 或 Codex？”仅仅告诉用户云端 Agent 能够 7×24 小时运行、代表未来趋势，不足以让他们改变工作方式。

《与运气竞争》中提出了 Jobs to Be Done 理论：用户“雇佣”一个产品，是为了完成某项任务。“雇佣”意味着成本。即使企业内部工具免费，用户仍然需要投入学习和操作精力；如果工具无法完成任务，还要切回原来的方式。

沿着这一思路，我们认为，托管交付的黄金场景不是所有需求，而是那些开发者不愿意做、却又不得不做的小需求。

第一类是工单类需求，例如 MySQL 相关修改、安全工单、FastJSON 漏洞升级以及线上 NPE 异常修复。这些问题通常很小，但如果专门为此开启一个完整迭代，成本又过高。

第二类是体验优化需求，例如增加按钮、调整表格尺寸或修改交互细节。这些工作必须完成，但对很多工程师来说吸引力有限。

第三类是重复性需求，例如简单 CRUD、协议转换等。菜鸟接入第三方服务商时，需要把对方提供的能力转换成菜鸟内部网关可以调用的协议。这类任务重复度高，开发者通常也不愿意反复手工处理。如果 Agent 能够自动完成这些工作，相当于为开发者增加了一个帮手，接受阻力会小得多。

这类场景还有一个天然优势：它们往往能够直接确定需要修改的应用和代码仓库。GitHub 之所以能成为天然的 A-to-A 协作平台，是因为 Issue 本身就属于特定代码仓库。一个 Agent 提交 Issue，另一个 Agent 修复问题并创建 Merge Request，任务边界非常明确。

企业内部的一般业务需求则不同。用户提出需求后，往往还要依赖专家经验判断涉及哪些应用。工单、安全问题和异常日志通常已经带有应用信息，因此更适合直接交给 Agent。

理想状态是，Agent 每天主动发现并完成一批此类任务，再通知工程师：“这个问题已经修复，请确认是否合并和发布。”此时，托管交付不再是另一个开发工具，而是一个直接完成待办工作的 Agent。

《跨越鸿沟》提出，新技术从早期市场走向主流市场时，必须先在一个细分领域打透。对托管交付而言，这些开发者不愿意做、又不得不做的小需求，就是当前最值得突破的场景。

AI 研发效能不能只看代码贡献率

当 AI Coding 贡献率达到 80% 或 90% 后，仍然要回答老板和 CEO 的问题：So what？

为了回答这个问题，我们研究了研发效能度量框架的演进。

较早期的 DORA 框架从四个维度度量交付流水线的质量和效率：部署频率、变更前置时间、变更失败率和服务恢复时间。它关注交付速度和质量，但没有回答团队目标是否真正达成。

换句话说，DORA 更关注是否正确地完成了一件事，却不一定关注团队做的是不是正确的事、是否创造了业务价值。

2021 年提出的 SPACE 框架进一步扩展了评价维度，包括研发满意度、质量与效率、工作活动分布、协同效能，以及效率与心流等。它更加全面，但每个维度下又有大量指标，最终可能形成一个大而全的体系，团队仍然不知道应该优先优化什么。

2023 年，业界开始更多讨论 DevEx，即开发者体验。DevEx 主要关注心流、反馈闭环和认知负荷，希望通过消除开发过程中的摩擦点提升效率。

反馈闭环尤其重要。大模型能力提升后，前端工程师往往更早感受到冲击，一个原因就是前端的反馈闭环很短。输入 Prompt、增加按钮或修改页面后，结果可以立即呈现，验证成本很低；后端开发的反馈链路通常更长。一次修改可能引入性能问题或其他 Bug，仅通过代码表面很难发现。反馈闭环越短、认知负荷越低，开发者越容易进入心流，效率也越容易提升。

但 DevEx 同样存在局限：**体验改善不一定等于效能提升。**在 AI 时代，团队可能为了提高 AI Coding 贡献率，持续与 AI 进行大量没有实际价值的对话。指标上涨了，业务产出却没有增加。

因此，我们认为仍然需要一个北极星指标，从“多、快、好、省”的角度回答 AI 带来了什么变化。例如：

• 单位周期内，人均交付的需求数量是否增加；
• 需求整体交付周期是否明显缩短；
• 工单数和故障数是否下降，代码质量是否提升。

对于非技术岗位，特别是需要向管理层解释 AI 价值时，北极星指标能够提供清晰牵引。

但只有一个北极星指标也不够。**当一个指标变成唯一目标时，它往往就不再是一个好指标。**因此，还需要设置检查指标，相互佐证和制衡。

例如，人均交付需求数增加时，需要检查需求拆分的颗粒度是否变小。如果团队只是把原来的一个需求拆成多个更小的需求，数字虽然上涨，实际产出并没有变化。评估交付周期时，同样需要排除需求规模变化带来的影响。最后还要认识到，研发效能度量就像一座冰山。水面之上是能够统计的指标，水面之下则是组织架构、技术架构、业务阶段和组织文化。

根据康威定律，系统架构与组织架构密切相关。企业所处的业务阶段不同，适用的效能指标也会不同。大量影响研发效率的因素无法直接量化，因此，指标不应被当作绝对答案，而应当用于观察趋势、发现摩擦点并推动优化。

结语

回顾菜鸟从 AI Coding 到需求托管交付 Agent 的实践，我想总结四个判断。

第一，企业推动 AI Coding 落地，可以先抓住“三板斧”：使用先进模型、选择好用的 Coding Agent、对关键指标进行度量和公开展示。

第二，要让 Agent 完成需求交付这样的长程任务，可以采用通用 Agent 作为 Harness、Plugin 承载能力、Playbook 描述流程的组合，并通过结构化任务状态保证执行的确定性。

第三，完成一个新产品之后，必须回到用户视角，理解用户愿意“雇佣”它完成什么任务。只有把具体场景做透，产品才有机会跨越从早期尝试到规模化应用之间的鸿沟。

第四，研发效能度量的目的不是追求好看的数字，而是发现交付过程中的摩擦点。用北极星指标提供方向，用多维检查指标相互制衡，再结合组织和业务背景观察趋势，才能接近 AI 创造的真实价值。

嘉宾介绍：

**郭凤钊，**菜鸟网络研发总监，菜鸟 AI 研发效能负责人 / 架构师，负责研发效能、稳定性与 FinOps 体系，双 11 等大促技术 PM。专注于 AI 赋能企业研发效能的实践与落地，是菜鸟内部 AI 技术布道的核心推动者。鲲鹏会杭州会员。

41 AI Coding 之后，如何让 Agent 进入企业研发全链路？得物推荐的 Harness 实践

在 AICon 全球人工智能开发与应用大会上，InfoQ 邀请得物资深技术专家白忠魏带来演讲，分享得物推荐团队在企业级复杂系统中推进 AI 研发实践的思考与经验。

演讲中，白忠魏从得物推荐的业务与工程场景出发，围绕“如何让 AI 从写代码走向完整研发迭代”这一问题，介绍了团队在 PDCA 全链路、七阶段护栏、TPRD、研发环境与测试验证、AI 推荐质量评测、三层知识体系，以及 Highway + ATV 混合 Agent 架构等方面的探索，并分享了阶段性的实战数据。

以下为演讲内容，经 InfoQ 整理。

从 AI Coding 走向 AI 全链路

目前，AI Coding 已经能够较好地完成从 0 到 1 的项目和相对简单的编码任务。在部分场景下，它交付的结果甚至会超出工程师的预期。对于这一点，行业内已经形成了较为明确的共识。

但在企业级项目中，AI 面临的环境要复杂得多。如果面对的是一个运行了十几年、代码量庞大的老项目，或者一个横跨多个系统和业务层级的超大型项目，AI 能否准确理解需求、控制影响范围，并对最终结果负责，仍然是一个需要持续探索的问题。

得物推荐也在推进类似实践。我们的目标并不只是让 AI 写代码，而是将 AI Coding 扩展为一套覆盖需求、开发、验收和问题反思的 AI 全链路方法。

得物推荐本身是一套较为复杂的系统。用户进入得物后，看到的推荐内容大致可以分为两部分：一部分是商品交易推荐，接近淘宝、京东的场景；另一部分是帖子和内容推荐，接近内容社区或短视频平台的场景。

整套系统包含召回、粗排、精排、推荐引擎以及大量上下游服务，是一个历史较久、规模庞大的复杂工程。如何让 AI 真正进入这类系统的研发流程，正是我们这次实践的出发点。

AI 驱动的研发迭代飞轮

从软件工程视角看，一次完整的研发迭代可以抽象为 Plan、Do、Check、Act 四个阶段，也就是常见的 PDCA 循环。

Plan 是需求对焦。需求开始后，产品经理和技术团队需要围绕目标、边界、上线时间和验收标准达成一致。这个阶段的主要产出包括 PRD、研发排期，以及判断需求是否达到预期的成功标准。

**Do 是开发实现。**这一阶段不仅包含编码，还包括上下游联调、单元测试、集成测试和功能验收，最终产出代码、单元测试及发布方案。

**Check 是效果校验。**需求开发完成后，需要经过测试验证、灰度发布和指标观测，判断功能上线后的真实效果。

**Act 是分析、反思和问题排查。**对于推荐业务而言，功能上线并不意味着研发过程结束。团队还要继续观察业务指标，处理体验类和功能类问题；一旦出现 Bad Case，便需要分析原因，并将结论带入下一轮迭代。

目前，多数团队的 AI 实践主要集中在 Do 阶段，也就是让 AI 写代码。在需求产出、测试验收、业务效果判断，以及最后的 Bad Case 分析和问题反思中，AI 的参与程度仍然有限。

我们希望做的，是将这些环节真正串联起来，让 AI 不只参与开发，而是进入完整的 PDCA 循环。

全链路 AI 化的四个前提

如果希望 AI 参与完整研发流程，那么每一个阶段都必须具备清晰的约束和判断标准。

在 Plan 阶段，需求必须足够明确，目标和边界不能反复摇摆。如果一开始的目标是 A，执行过程中又不断变成 B，后面的开发与验收就无从谈起，AI 也无法稳定执行。

在 Do 阶段，AI 的执行过程应尽量减少中断。理想状态下，工程师给出任务后，AI 可以持续运行较长时间，而不是频繁因为环境、依赖或信息不完整而向人提问。虽然距离完全自主执行仍有差距，但研发环境应尽可能降低 AI 的等待成本。

在 Check 阶段，结果必须能够量化。AI 和推荐系统在一定程度上都具有黑盒特征，我们很难了解内部每一步的全部细节，因此需要通过测试结果和后验数据判断产出是否可靠。

在 Act 阶段，经验必须能够复用。过去踩过的坑不能在后续任务中反复出现。我们会要求工程师不要在同一个问题上重复犯错，对 AI 也应当建立同样的要求。

最终，我们希望提高 AI 在整个需求链路中的渗透率和产出采纳率，同时缩短研发迭代周期。很多团队目前按照周或双周进行迭代，如果 AI 能够参与完整链路，双周迭代有机会缩短到周，周迭代则有机会缩短到天。更理想的状态是，一轮任务完成以后，系统能够自动进入下一轮，而不再受固定迭代周期的限制。

好的 Harness，是环境而不是铁笼

可以借用《楚门的世界》理解 AI Harness 的作用。

电影中，楚门生活在一个巨大的摄影棚里。摄像头、演员、天幕和围墙都在限制他的行动，但真正让他不敢离开小岛的，其实是水。童年经历使他对水产生了强烈恐惧，因此水并不是一面写着“禁止离开”的墙，而是成为了环境本身。

好的 AI Harness 也应当如此。

Harness 的作用不是在 Prompt 中堆叠大量“不要”“禁止”和“必须”，而是搭建一个让 AI 自然按照预期方式运行的环境。

如果为 AI 增加过多显性的限制，它反而可能因为无法同时满足所有条件而停止执行。更有效的方式，是把约束融入环境、工具和验证流程中，让 AI 在执行任务时，自然按照既定方式运行。

基于这一思路，我们按照 PDCA 四个环节进一步抽象出了七阶段护栏，并从护栏能力、护栏载体和约束逻辑三个方面设计整套全链路体系。

在这套体系中，人仍然承担着不可替代的作用，尤其是在技术方案评审，以及 Check、Act 两个阶段。

技术方案评审是 AI 开始长时间自主执行之前，最后一个能够由人进行双层 Review 的位置。AI 真正开始编码前，需要先提交计划采用的方案，由工程师判断其对需求的理解是否准确、技术方向是否存在偏差。否则，AI 可能沿着错误方向持续运行很长时间。

Check 和 Act 阶段则不应只关注线上稳定性。目前很多团队更擅长判断系统是否报错、接口是否超时、服务是否异常，却缺少对业务效果的智能化判断。如何让 AI 参与业务结果分析，也是全链路建设中需要继续完善的能力。

在 Plan、Do、Check、Act 中建立工程护栏

Plan：用 TPRD 和 Contract 把需求变成可执行边界

日常需求讨论通常采用自然语言。自然语言的问题在于，即使所有人都认为自己理解了，同一句话在不同角色眼中仍然可能具有不同含义。

为此，我们在 PRD 之后增加了一层 TPRD，并在其中引入 Contract。Contract 用来提前明确需求会影响哪些模块、优化目标是什么、应该朝哪个方向调整，以及有哪些技术约束不能突破。

技术团队也会将需要明确的技术条件提前反馈给产品同学，使需求得到更加结构化的描述。这样，AI 真正开始执行时，拿到的就不只是一段自然语言，而是一套可以理解和遵守的边界。

TPRD 是后续所有阶段的围栏。目标和方向如果不清楚，代码写得再快、测试做得再完整，也可能只是在错误方向上努力。

我曾经带一位同学去开会，原本应该去 5 号楼，结果却走到了 4 号楼。那位同学对我说：“如果方向走偏了，怎么努力都没有用。”这句话也可以概括我们建设 TPRD 的核心原因。

例如，产品提出一个需求：“用户点击不感兴趣后，少推荐一些类似商品。”这句话看起来很容易理解，但从技术角度继续拆解，就会发现其中包含大量待澄清的问题。

用户不感兴趣的究竟是这个商品、这个品牌，还是所属类目？他可能只是不喜欢商品图片，也可能不喜欢内容作者。“少推荐一些”也可能有多种含义：是以后完全不再出现，还是三天内减少曝光？是几个小时内降低频率，还是长期降低权重？如果用户不喜欢某个品牌，系统又应该在什么条件下重新恢复推荐？

如果这些问题没有在需求阶段明确，AI 后续无论采用什么方案，都可能与产品真正想要的结果产生偏差。

因此，完成 PRD 后，我们会通过 TPRD 将需求进一步拆解为多个 EP，也就是具体的功能点。对于每一个 EP，团队都会明确需要修改的位置、实现目标、约束条件、实验方式和验收标准。

**TPRD 负责把需求拆解成可执行的 EP，Contract 则负责为每一个 EP 划定边界。**这些内容共同构成后续开发、测试和验收阶段的“北极星”。

Do：通过三类基础设施减少 AI 等待

进入 Do 阶段后，需要解决的核心问题是：如何让 AI 持续执行更长时间，而不是不断因为环境、依赖或验证问题停下来。

围绕这一目标，我们主要建设了三类基础设施。

**第一类是沙箱隔离。**大型企业项目通常依赖复杂的中间件、下游服务、内部环境和线上数据，本地机器很难完整还原。如果 AI 每写一点代码，都需要工程师部署到其他环境，再拉取日志、检查结果，它就不可能实现真正的自主运行。

因此，我们通过本地可运行环境、代理或预发等方式，让 AI 和工程师可以一边修改代码，一边执行并获取日志。对于无法在本地完整运行的能力，则通过代理或预发环境进行补充。这样，AI 完成一轮代码修改后，就可以立即执行和校验，不必等待工程师到其他系统中获取反馈。

第二类是 UTD，也就是单测驱动。大家比较熟悉的是 TDD，即先通过测试描述功能，再根据测试完成代码。但 AI 本身是一个黑盒，由 AI 生成的单元测试同样可能存在偏差。如果 AI 一次生成大量测试，工程师仍要投入很多时间判断这些测试是否真正有效。

我们的思路是通过数据形成验证闭环。例如，AI 修改代码前，线上已有 2500 个用例；修改后，AI 又新增了 100 个用例，总数变成 2600 个。如果重新执行后发现其中有 400 个不通过，AI 就可以根据数据反思：代码是否改错、是否影响了原有逻辑，或者是否引入了不符合预期的行为。

我们不仅让 AI 编写单元测试，也让它根据已有测试和新增测试的执行结果，判断自己的修改是否可靠。

**第三类是外部依赖 Mock。**推荐系统存在大量下游服务和随机条件，同一个用户每次刷新，看到的推荐结果都可能不同。如果外部输入一直变化，就很难准确判断本次代码修改究竟造成了什么影响。

因此，我们会通过 Mock 将可能变化的下游依赖静态化，包括推荐引擎、下游服务以及具有随机性的条件。只有输入和外部依赖保持稳定，系统才能准确评估一段代码影响了哪些范围、造成了多大变化。

这三类基础设施最终服务的不只是 AI，也服务于工程师。Harness 是给 AI 使用的，同时也是为人建设的。AI 可以在本地编码、运行和验证，工程师同样不必反复等待联调环境。

Check：用 AI 模拟用户，把推荐质量评测前置

推荐系统具有比较明显的黑盒特征。一项功能上线后，我们通常只能根据用户后续的行为，判断这次调整究竟是好还是不好。

传统验收往往依赖人工评测。测试人员需要观察推荐结果的新颖性、质量和画风，判断这些内容是否符合用户兴趣。这一过程非常消耗人力和注意力。我们实际测试过，一名同学每天工作 8 小时，最多大约只能评测 200 条结果；继续增加评测量后，人的注意力和判断质量都会明显下降。

因此，我们尝试用 AI 模拟真实用户画像，对上线前后的推荐结果进行评审。团队会预先定义新颖性和质量标准，再由 AI 按照 L1-L5 对推荐结果进行分级。这样，功能正式上线前就可以完成推荐质量的前置审核，评测也能够逐渐从一次性人工工作转变为 7 × 24 小时的常态化运行。

在这套平台中，每一个 AI 评审员都对应一类用户画像。画像中包含性别、年龄、购买力和人生阶段，也会结合季节、节日等时空信息，以及用户是否浏览、购买过某类商品等历史行为。

AI 会站在特定用户的角度，判断其对当前推荐结果的兴趣，再根据预先设定的维度进行评分。

目前，AI 的评测准确率还没有完全与人工对齐，但人工评测本身同样存在偏差。不同的人面对同一组推荐结果，也可能给出不同判断。更重要的是，AI 的判断过程和评测结果可以被完整保留下来，再由专家进行抽样和二次审核，最终形成可复用的评测资产。

例如，秋季适合推荐大闸蟹；进入冬季后，可以面向部分价格敏感型用户推荐反季服装。这些经验过去可能只存在于少数专家的认知中，现在则可以逐渐沉淀为系统能够复用的知识。

Act：让问题排查结果沉淀为 Story

在 Act 阶段，我们建设了线上问题排查工具“推查查”。线上监控发现异常，或者业务侧出现舆情 Bad Case 后，问题会进入推查查，由人工和 AI 同时进行排查。

问题处理完成并不代表流程结束。团队还会继续复盘问题产生的原因、排查过程中走过的路径、真正有效的信息，以及未来遇到同类问题时如何更快获得答案。

复盘结果最终会沉淀为 Story。

**这里的 Story 不是 Skill。**它并不是一段等待 AI 下次重新理解的经验总结，而是要将已经验证过的问题排查路径转化为更加确定、可编码、可重复执行的方案。

通过这些阶段的建设，我们尝试让 AI 从产品提出需求开始，一直参与到开发、验收、效果判断、线上问题诊断和经验反思。不过，当 AI 真正进入完整链路后，知识丢失、随机漂移和路径不透明等问题也会随之暴露出来。

用 CDD 和三层知识体系解决知识丢失

第一个问题是知识丢失。大模型的上下文容量必然有限，同一类任务上周已经向 AI 解释过一次，下周仍然可能需要重新说明。工程师在使用 AI Coding 时，经常会遇到类似情况：之前已经交代过的内容，AI 在后续对话中再次忘记，导致沟通不断重复。

第二个问题是随机漂移。即使任务和 Prompt 完全相同，AI 今天和明天也可能采用不同的处理方式。我曾要求 AI 调用一个工具，它反馈工具已经执行，并返回了响应结果。但通过调用日志检查后发现，它实际上并没有调用工具，所谓的结果是它自行 Mock 出来的。在企业级应用中，这类问题具有很高的风险。

第三个问题是路径不透明。Agent 本身仍然具有黑盒特征，出现问题后，团队未必知道它究竟卡在哪一个步骤。很多时候只能反复调整 Prompt，却很难迅速定位根本原因。

这些问题看似来自模型，但要解决它们，首先需要回到工程自身。如果人都无法从代码库中找到准确知识，AI 同样不可能稳定理解系统。

从代码注释切入知识建设

程序员经常面临一个矛盾：一方面希望别人留下完整文档，另一方面又不愿意自己维护文档。时间一长，代码库中的文档要么缺失，要么与代码不同步，真正遇到问题时很难依赖。

代码本身也可能存在歧义。例如，一个变量名是 isCannotShow，值却等于 false。即使是工程师，也需要经过多层判断，才能确认此时究竟应该展示还是不展示。

如果工程自身的知识表达都不清楚，一开始就要求 AI 自动解决这些问题，同样很难取得稳定结果。

我们的做法是 CDD，也就是 Comment-Driven Development。先让 AI 补注释，而不是一开始就让它补文档。

之所以从注释开始，是因为注释距离代码最近。AI Coding 时，AI 可以同时读取代码和注释，理解常量含义、局部逻辑和设计意图。这些知识可以跟随代码一起被读取，也更容易在代码发生变化时及时更新。

但注释只能解决局部代码的知识问题，不能代替模块设计文档，也不能承担团队级行为约束。因此，CDD 并不是把所有知识都放进注释，而是从最贴近代码的一层切入，再将不同类型的知识组织为完整的三层体系。

L1、L2、L3 各自解决什么问题

企业级系统中的知识具有不同的作用范围：有些是任何任务都不能突破的团队规则；有些用于解释模块为什么这样设计；还有一些需要跟随代码持续更新。

基于这一差异，我们把 AI Coding 所需的知识组织为 L1、L2、L3 三层。这里的层级不是简单的重要性排序，而是同时区分约束强度、知识范围和 AI 的取用方式。

**L1 是不可逾越的行为边界。**这是作用于整个研发过程的团队级硬约束。例如，写代码必须配套单元测试，或者团队要求代码注释率必须超过 30%。无论 AI 修改哪个模块、选择什么实现方式，都不能突破这些规则。L1 不负责解释某段代码如何运行，而是规定 AI 在研发过程中始终必须遵守什么。

**L2 是模块级的设计知识。**这一层用于解释模块为什么这样设计，并沉淀关键依赖关系。它通常需要架构师和技术负责人参与梳理。由于模块设计不会每天变化，这部分知识的更新频率相对较低，可能半年才调整一次。但当 AI 处理跨模块需求或者复杂问题时，L2 可以提供必要的架构背景。

只看一段代码，AI 可能知道这里调用了某个接口，却不知道为什么必须这样调用，也不知道该模块与其他模块之间存在什么约束。L2 的作用，就是补足这些上下文。

**L3 是与代码直接关联的注释知识。**这是距离代码最近的即时知识，会随着代码变化而更新，也是 AI Coding 处理具体任务时最先接触到的内容。它主要帮助 AI 理解“这个常量是什么意思”“这段逻辑在做什么”“为什么这里需要这样处理”等局部问题。

这三层知识在执行时，并不是让 AI 机械地从 L1 读取到 L3。L1 作为硬边界，在整个任务执行过程中始终生效；AI 处理具体任务时，会先结合代码读取 L3，如果局部注释不足以解决问题，再启用 L2，查看模块设计、关键依赖以及周边关联模块。

换句话说，L3 回答的是“这段代码是什么、在做什么”，L2 补充的是“这个模块为什么这样设计、与哪些模块相关”，L1 约束的则是“无论采用什么方案，都不能违反什么”。

通过这种方式，知识不再集中在一份容易过期、与代码分离的大文档中，而是根据不同作用范围，放在距离使用场景最合适的位置。完成三层知识建设后，AI 才有可能回答更多需求阶段的问题，例如某项功能之前是否已经有人做过、当时如何实现，以及上线后的实际效果如何。

补齐注释后，准确率从约 52% 提升到 90% 以上

我们对这套知识体系的效果进行了一些验证，测试问题大致分为简单问题和复杂问题。

简单问题包括“这个常量是什么意思”“这段代码在做什么”。过去，面对缺少注释的代码，AI 只能根据变量名和上下文猜测；补齐注释后，这类问题通常一次就能得到较为准确的回答。

复杂问题可能横跨多个系统，甚至工程师自己也没有现成答案。测试结果显示，在没有注释的情况下，AI 回答问题的整体准确率约为 52%；补齐注释后，准确率可以达到 90% 以上，追问次数和总体 Token 消耗也随之下降。

对于复杂问题，单次调用的 Token 数量可能有所增加，因为注释本身也需要占用上下文。但从整个问题解决过程来看，总体 Token 消耗仍然下降了。原因在于，AI 获得了更多有效知识，不再需要反复追问工程师，也减少了在错误路径上的无效尝试。

单次读取的信息增加了，但解决问题所需的对话轮次减少了。

用混合 Agent 架构对抗黑盒与随机漂移

80% 走 Highway，20% 走 ATV

解决知识丢失以后，还需要继续处理 Agent 的黑盒特征和随机漂移。为此，我们在推查查中采用了一套混合 Agent 架构，其设计思路来自二八定律。

对于 80% 的高频问题，我们希望系统具备较强的确定性，这条路径被称为 Highway，也就是高速公路。剩余 20% 的问题通常属于没有现成解决路径的长尾场景，这部分进入 ATV 路径，允许 AI 进行更加自由的探索。

大部分已知问题走 Highway，通过确定性路径快速解决；少量未知问题走 ATV，由 AI 自主探索。

系统最上层设置了意图识别模块。问题进入后，系统首先判断过去是否出现过类似问题：如果已经出现过，就直接进入 Highway；如果从未出现，则进入自主探索路径。

在两条路径下面，我们还设计了一个进化层。今天进入 ATV 的长尾问题，在经过 AI 与人的多轮对话并得到解决后，会通过反思重新沉淀，最终进入 Highway。随着问题不断积累，Highway 中的确定性能力会持续增加，需要 ATV 自由探索的问题则会逐渐减少。

人和 AI 都会猜测，代码不会

“出去买两根香蕉，如果看到卖苹果的，就买四个”是一句经常被用来讨论自然语言歧义的话。

有人会将它理解为买两根香蕉，如果看到苹果就再买四个苹果；也有人会理解为看到苹果后，把香蕉的数量改为四根。自然语言存在歧义，人会根据上下文补充信息，AI 同样会进行猜测。

但如果条件被写成代码，结果就会变得确定。假设代码明确规定，如果看到卖苹果的，就把香蕉数量改成四根，那么这段代码无论运行一遍还是一万遍，结果始终都是四根香蕉。

人会理解和补全，AI 也会理解和补全，但代码不会。

这正是 Highway 的核心思路：把所有已经明确的问题转化成代码。

Highway：将已知问题全部代码化

对于已经出现过的问题，我们会将排查过程编码成确定的执行逻辑。每类问题都有对应代码，也有明确的适用场景。

问题进入系统后，意图路由首先判断它是否属于已知问题。如果能够匹配，就不再让 AI 重新推导，而是直接执行经过验证的代码。

这样做可以显著提高确定性。如果每次都让 AI 根据一段 Skill 重新理解问题，它仍然可能选择不同的工具、不同的执行顺序，并得到不同结果。代码一旦经过验证，则能够按照固定路径稳定执行。

对于已知问题，不要让 AI 每次重新思考，而是先让它执行已经验证过的代码。

ATV：未知问题先探索，再通过反思进入 Highway

对于无法匹配已知路径的长尾问题，我们会允许 Agent 自主探索。实践中，团队尝试过 OpenClaw，也就是大家常说的“龙虾”，也使用过 Hermes 等方式，并向 Agent 提供相应的 Skill、MCP 和工具调用策略。

这个过程更像一名工程师面对未知问题：他可能需要查看多个系统、调用不同工具、验证不同假设，并与其他人进行多轮沟通，才能逐渐确定最终答案。对于未知问题，暂时无法要求 AI 一开始就具备完全确定的执行路径，先让它自主探索是更加现实的选择。

但如果每次遇到类似问题，都重新进行一遍探索，效率仍然会很低。因此，ATV 之后还有一个重要的反思过程。

一个长尾问题经过 AI 和人的多轮对话并得到解决后，我们会在每天晚上触发反思。反思的目的并不是让 AI 再写一段 Skill，告诉未来的 AI 遇到类似问题时应该怎么做，因为 Skill 仍然需要 AI 在下一次执行时重新理解，只要存在重新理解，就可能产生新的随机性。

我们要求 AI 将当天已经解决的问题重新转化成代码。

随后，由人根据 Checklist 对生成的代码进行检查，并与 AI 共同完成最后的校验。通过验证后，这段代码就成为新的 Story，进入 Highway。原本属于长尾范围的问题，下一次再出现时，就可以进入确定性路径。

这也是 Story 和 Skill 的核心区别：Skill 是一段需要 AI 再次理解的能力说明，Story 则是经过实际问题验证并被固化为代码的执行经验。

**我们的经验是，代码永远是稳定的。**代码无法预先解决所有未知问题，但只要一个问题已经被解决并完成验证，就应尽量将其过程固化下来，使经验从“可参考”转变为“可重复执行”。

阶段性实战结果

这套体系建设的时间还不算特别长，但已经取得了一些阶段性结果。目前，AI 在需求链路中的渗透率约为 30%，相比过去，AI 在完整研发链路中的参与度已经明显提升。

当然，并不是所有需求都适合让 AI 参与。例如，只需要修改一行配置时，工程师自己很快就能完成，没有必要为了使用 AI 而强行引入一套复杂流程。

我们的目标不是追求形式上的 AI 覆盖率，而是在真正适合的环节提高 AI 的参与度、产出采纳率和交付效率。

在问题排查方面，整体效率得到明显提升，处理时长相比过去下降了约 80%，部分场景的提升可能更高。

传统做法通常将经验沉淀为 Skill，下一次遇到问题时，AI 仍然需要经过多轮理解、规划和工具调用。将已知问题代码化后，一轮执行就可以跑完，处理速度可以接近人工，部分场景甚至比人工更快。

结语：让人和 AI 在同一个“梦境”中工作

OpenClaw 提出过一个很有意思的概念——“梦境”。这让人联想到庄周梦蝶：究竟是庄周变成了蝴蝶，还是蝴蝶变成了庄周？在梦境中，双方的边界已经不再清晰。

AI Harness 也是如此。在 Harness 中执行任务的究竟是 AI 还是人，并不是最重要的问题。AI 会遗忘、会犯错，人同样会遗忘、会犯错；人需要沉淀经验，AI 也需要建立自己的经验体系。

真正重要的是，在“梦境”的边缘搭建好 Harness，让执行者自然理解当前环境，遵循已经定义好的边界，并能够持续验证、反思和积累经验。

当需求边界足够清晰、开发过程能够验证、业务效果可以量化、问题经验可以复用时，AI 才能从一个写代码的工具，真正成为企业研发迭代飞轮的一部分。