AI越强,人越要像人——行动篇:程序员打造AI工作流的6个关键步骤

AI越强，人越要像人——行动篇：程序员打造AI工作流的6个关键步骤

引言：从知道到做到

上周三晚上，徒弟小王又来找我喝酒了。

这已经是这个月第三次了。前两次，他跟我聊的都是"AI会不会取代程序员"、"我们该怎么办"这种焦虑话题。但这次不一样，他一坐下就掏出电脑，兴奋地给我看他的成果。

"师父，你看！我把代码review的流程自动化了，以前每次要花两小时，现在15分钟就搞定了。"

屏幕上是他设计的一套半自动化工作流：AI先做初步review，标注出潜在问题，他只需要重点审查那些真正需要人工判断的地方。

我问他："花了多久？"

"两周。一开始想一步到位搞个全自动的，结果发现AI总是会漏掉一些业务逻辑。后来我改了思路，让它做能做的，我来做该做的。"

小王的转变让我想起很多程序员对AI的态度——要么觉得它是救命稻草，什么都往上面靠；要么觉得它是洪水猛兽，避之唯恐不及。其实都不是。AI就是工具，就像你的键盘、你的IDE，关键是你怎么用它。

今天这篇文章，我不讲那些大道理，就讲一件事：怎么真正把AI用起来，让它成为你的生产力放大器。不是听说，不是围观，而是行动。

六个步骤，一步步教你打造自己的AI工作流。每个步骤后面都有行动清单，看完就能动手。

金句：知道和做到之间，隔着两个字：行动。

第一步：找到你的"低垂果实"

是什么

"低垂果实"这个词源自一个故事：一棵树上，有的果子长在低处，伸手就能摘到；有的长在高处，需要爬树才能摘到。在AI时代，低垂果实就是那些AI能做得好、你又经常做的任务。

不是所有事情都适合用AI。你用AI帮你写复杂的业务逻辑代码？大概率翻车。你用AI帮你做架构设计？可能得到一堆看似合理但完全落不了地的方案。

真正的低垂果实有三个特征：

1. 重复性：这件事你经常做，每次都差不多

2. 探索性：需要尝试很多方案，但试错成本低

3. 创意性：需要发散思维，但结果质量可以快速判断

怎么做

拿出一张纸，列出你一周内做的所有任务。然后逐个打分：

重复性：1-5分，5分表示天天做
探索性：1-5分，5分表示需要尝试很多方向
创意性：1-5分，5分表示需要大量创意

三项总分10分以上的，就是你的低垂果实。

常见的低垂果实包括：

代码文档撰写
单元测试用例生成
API接口设计初稿
技术方案框架搭建
Bug分析和修复建议
代码重构建议
技术文章大纲生成

曹老师实践

我最早找到的低垂果实是"代码注释"。

之前带团队的时候，我总要求新人写注释，但写出来的注释五花八门——有的写得像小说，有的干脆不写。后来我就让Claude帮我生成注释模板，给一段代码，它能生成符合规范的注释，还能把复杂逻辑讲清楚。

但这里有个关键点：我不是让它直接生成最终注释，而是让它生成"建议注释"，我来审核修改。为什么？因为AI有时候会过度解释一些简单逻辑，或者漏掉业务背景。这些都需要人来把关。

节省下来的时间，我能多做两件事：一是指导新人的技术细节，二是多看几遍代码本身的质量。

再后来，我又找到了第二个低垂果实："技术方案评审"。

以前写技术方案，我要花至少两个小时构思结构，还要画各种图。现在我只需要给AI一个需求描述，它能生成一个完整的方案框架，包括架构图（用Mermaid画）、接口设计、风险点分析。我能做的，就是在这个基础上填充业务细节。

这比从零开始写要快至少三倍，而且质量更稳定。

常见误区

误区一：什么都要用AI

有些人一听到AI就想把所有事情都自动化。写代码用AI，改bug用AI，做架构用AI，甚至用AI来决定中午吃什么。结果是啥呢？效率反而更低了——因为你要花时间跟AI沟通，要判断它给的答案对不对，还要为它犯的错误买单。

记住：AI不是万能的，它只是个工具。用错地方，反而帮倒忙。

误区二：等到完全准备好了再用

我见过很多人，说要先用三个月系统学习AI，等完全掌握了再开始实践。三个月后呢？他们还在学习。

学习AI和学开车一样，理论看再多，不如上车开一圈。先从小事开始，边用边学，进步更快。

行动清单：

[ ] 列出你最近一周做的所有任务（至少20项）
[ ] 对每项任务进行打分（重复性、探索性、创意性，各1-5分）
[ ] 挑出总分10分以上的3-5项，作为你的"低垂果实"
[ ] 选择其中1项，今天就用AI试一下（哪怕是试错）

第二步：建立你的提示词库

是什么

提示词（Prompt）就是你给AI的指令。很多人第一次用AI，要么不知道说什么，要么每次说的都不一样，导致输出质量忽高忽低。

提示词库就是把那些好用的提示词分类整理起来，随时能用。就像你的代码片段库一样，不是每次都从头写，而是从库里面拿出来改一改。

怎么做

一个实用的提示词库应该满足三个条件：

1. 可复用：提示词本身不包含特定业务细节，但能快速适配

2. 可组合：不同提示词可以拼接，应对复杂场景

3. 可迭代：用了觉得好的就留下，不行的就优化或删除

建议按场景分类：

代码类：代码生成、代码review、代码解释、代码重构
文档类：技术文档、API文档、用户手册
方案类：技术方案、架构设计、风险评估
学习类：概念解释、案例分析、问题诊断
创意类：标题生成、结构梳理、风格调整

曹老师实践

我的提示词库最早是在Notion上建的，后来迁移到了Obsidian。最开始很乱，几十条提示词堆在一起，想用的时候找半天。

后来我做了三件事：

第一，分类。我把提示词分成五大类，每类下面再细分场景。比如"代码类"下面有"代码生成"、"代码review"等。

第二，标注。每个提示词都标清楚适用场景、输入要求、输出格式。比如我的"代码review"提示词就写着：

适用场景：JavaScript/TypeScript代码review输入要求：完整代码文件输出格式：1. 代码质量评分（1-10分）2. 潜在问题列表（按严重程度排序）3. 具体修改建议（含代码示例）4. 代码风格建议

第三，迭代。每次用完提示词，我都会评估效果：好的就保留，不好的就优化。用了一段时间，我的提示词库里就剩下那些真正好用的。

现在，我的提示词库有60多条，但常用的只有20条左右。这20条覆盖了我80%的场景。

举个例子，我有一个"技术方案框架"提示词，长这样：

请根据以下需求，生成一个完整的技术方案框架：需求描述：{需求描述}请按照以下结构输出：1. 背景与目标2. 现状分析3. 方案设计 - 整体架构（用Mermaid绘制） - 核心模块说明 - 数据流程图4. 接口设计5. 技术选型6. 风险评估7. 实施计划8. 成功指标注意：- 架构图用Mermaid语法- 接口设计包含请求/响应示例- 风险评估至少列出5个潜在风险及应对措施

用的时候，只需要把"{需求描述}"替换成具体内容，其他都不用改。生成的方案框架质量很稳定，我只需要填充业务细节。

金句：提示词库就是你的AI工具箱，工欲善其事，必先利其器。

常见误区

误区一：追求完美的提示词

我见过有人花了几天时间打磨一条提示词，反复调整，想让AI一次性输出完美结果。但AI的能力有上限，再好的提示词也只能接近完美，不可能一步到位。

提示词库的价值在于"够用"和"快速"，而不是"完美"。80分但能10分钟拿到的结果，比95分但要花1小时的更有意义。

误区二：提示词库越大越好

有些人的提示词库动不动几百条，看起来很壮观，实际用的时候却找不到想要的。真正有用的提示词库，应该是小而精的。

我建议每类场景保留3-5条最好用的就够了。多了反而选择困难。

行动清单：

[ ] 选择一个笔记工具（Notion、Obsidian、飞书文档都可以）
[ ] 创建一个"AI提示词库"文档
[ ] 按场景创建分类（至少3类）
[ ] 收集5-10条你觉得好用的提示词
[ ] 为每个提示词标注适用场景、输入要求、输出格式
[ ] 本周用完每个提示词至少1次，记录效果

第三步：打造半自动化工作流

是什么

半自动化工作流，就是"AI能做的交给AI，人该做的留给人"。

很多人对自动化有一个误区：要么100%自动化，要么干脆不用。但实际上，真正能100%自动化的场景很少，更多时候，我们需要的是半自动化——AI做大部分工作，人做关键的决策和校验。

半自动化的好处是什么？一是效率高，AI能快速完成重复性工作；二是质量稳，人能把控关键环节；三是风险低，出了问题有人兜底。

怎么做

打造半自动化工作流，需要分三步走：

第一步：拆解任务

把一个复杂任务拆解成多个小任务，判断哪些适合AI做，哪些必须人来做。

一般原则：

AI适合：信息检索、格式整理、内容生成、代码补全
人适合：业务决策、质量判断、价值评估、风险识别

第二步：设计流程

明确每个环节的输入、输出、负责人。画一个流程图会更清楚。

第三步：建立边界

明确规定AI的权限边界：哪些必须经过人审？哪些可以自动通过？出错怎么处理？

曹老师实践

我最有成就感的一个半自动化工作流，是"代码Review流程"。

以前我们的代码Review流程是这样的：

1. 开发者提交PR

2. 我review全部代码

3. 写一堆comment

4. 开发者修改

5. 再次review

6. 合并

这个流程有啥问题呢？一是慢，我每次review至少两小时；二是累，review时容易漏掉细节；三是重复，很多问题其实都是同一类错误。

后来我改造了这个流程，变成半自动化：

改造后的流程：

1. 开发者提交PR

2. AI自动review，生成report（包括代码质量评分、潜在问题列表、修改建议）

3. 我重点review AI标注的"高优先级问题"

4. 给开发者反馈（结合AI的建议）

5. 开发者修改

6. AI再次check，确认高优先级问题已解决

7. 合并

关键设计点：

AI的review范围：代码风格、命名规范、常见错误模式、安全风险检查
人的review范围：业务逻辑、架构设计、性能优化、扩展性考虑
边界规则：如果AI检测到"严重问题"，PR必须手动review；如果只是"建议性问题"，可以自动通过，但会在merge报告中备注

效果对比：

指标	改造前	改造后	提升
单次review时间	2小时	30分钟	75%
高优先级问题发现率	80%	95%	15%
重复错误率	40%	10%	75%

关键是我不仅省了时间，review质量还提升了。AI不会累，每次都按同样的标准检查，不会漏掉那些看似"不重要"但实际很重要的问题。

金句：半自动化的本质是"人机分工"，不是"人机替代"。

常见误区

误区一：追求全自动，一步到位

我见过有人花几个月搞全自动工作流，最后发现AI在某个环节总是翻车，整个流程跑不通，钱也花了，时间也浪费了。

自动化的正确节奏应该是：先手动，再半自动，最后（如果可能）全自动。一步步验证，风险可控。

误区二：把关键决策权交给AI

有些工作流，AI给出建议后直接执行，人工不审核。如果建议错了呢？如果AI被攻击了呢？如果业务场景变了呢？

关键决策必须有人把关，AI只能做建议和辅助。这是底线。

行动清单：

[ ] 选择你找到的1个"低垂果实"
[ ] 把它拆解成至少3个环节
[ ] 判断每个环节适合AI还是人来做
[ ] 画出流程图（可以手绘，也可以用工具）
[ ] 确定边界规则：哪些必须人审？哪些可以自动通过？
[ ] 本周把这个半自动化流程跑一遍

第四步：建立质量校验机制

是什么

AI不是完美的，它会产生幻觉、会理解偏差、会给出错误建议。所以，任何AI工作流都必须有质量校验机制。

质量校验分三层：准确性、安全性、业务性。

准确性校验：确保AI输出的内容在技术层面是正确的。比如代码能不能跑通，数据是不是合理，逻辑有没有漏洞。

安全性校验：确保AI输出不会带来安全风险。比如代码有没有注入漏洞，数据有没有敏感信息泄露，API调用有没有安全问题。

业务性校验：确保AI输出符合业务需求和规范。比如是不是符合产品逻辑，是不是符合团队规范，是不是符合用户体验要求。

怎么做

建立质量校验机制，需要做三件事：

第一，定义校验标准

每个工作流都要有明确的校验标准，不能凭感觉判断。比如代码质量，要有具体指标：代码行数、圈复杂度、测试覆盖率等。

第二，设计校验流程

明确谁来做校验、什么时候校验、发现问题怎么处理。可以是人工校验，也可以是AI校验，或两者结合。

第三，建立反馈闭环

校验结果要反馈给AI，让它在下一次表现更好。比如AI犯的错，可以记录下来，让它学习。

曹老师实践

我的"文档生成工作流"有一套完整的质量校验机制。

这个工作流是这样的：给AI一个技术需求，它生成技术文档（包括接口文档、用户手册、开发者指南）。但我不会直接用这个文档，而是要经过三层校验。

第一层：AI自我校验（准确性）

让AI自己检查：

接口参数是否完整？
代码示例是否能运行？
技术描述是否有矛盾？

AI生成文档后，我会让它运行一个self-check脚本，生成校验报告。如果发现明显错误，直接重新生成。

第二层：人工快速扫描（安全性）

我自己快速扫描一遍，重点检查：

有没有泄露敏感信息（比如内部接口地址、密钥）？
有没有误导性描述？
有没有安全隐患（比如让用户输入明文密码）？

这一层大概5分钟，但要确保文档不会出安全问题。

第三层：业务方确认（业务性）

把文档发给业务方（产品经理、运营、客服等），让他们确认：

接口是否符合产品需求？
用户手册是否容易理解？
开发者指南是否足够详细？

这一层是确保文档的实用性。

校验结果处理：

如果是准确性错误，直接让AI重新生成
如果是安全性问题，立即停用并修复
如果是业务性问题，跟业务方沟通后调整

关键点：

每层校验都有明确的通过标准和处理流程，不会出现"好像有问题但不知道该不该改"的情况。

而且，我会把校验中发现的问题记录下来，形成"问题库"。下次生成文档时，把问题库作为提示词的一部分，让AI避免重复犯错。

这样用了一个月后，文档的准确性从85%提升到了95%，安全性问题基本消失，业务方的满意度也明显提高了。

金句：没有校验机制的AI工作流，就像没有刹车的车，跑得越快越危险。

常见误区

误区一：只校验不改进

有些团队有校验机制，但只是"发现错误→修复错误"，没有把错误反馈给AI学习。结果是，同样的错误AI会反复犯。

校验的价值不仅是保证质量，更是帮助AI进步。一定要建立反馈闭环。

误区二：校验标准不明确

校验时凭感觉判断，这个"好像不对"、那个"可以接受"。结果是，不同人的判断标准不一样，质量忽高忽低。

校验必须有明确标准，最好是可量化的指标。

行动清单：

[ ] 为你的工作流设计三层校验：准确性、安全性、业务性
[ ] 为每层校验定义明确的通过标准（至少3条）
[ ] 设计校验流程：谁来做？什么时候做？发现问题怎么办？
[ ] 建立问题记录机制，记录AI犯过的错
[ ] 本周运行你的工作流，并把校验结果反馈给AI

第五步：持续迭代你的工作流

是什么

AI技术在快速发展，你的业务需求也在变化，所以你的工作流也需要不断迭代优化。

持续迭代不是一次性的工作，而是一个持续的过程。就像代码一样，不能写完就不管了，需要不断维护、优化、重构。

怎么做

我建议采用"每周优化一个环节"的方式，每周选一个环节进行深度优化，而不是试图一次解决所有问题。

具体步骤：

第一，收集数据

每周结束时，回顾一下工作流的运行情况：

哪个环节花时间最多？
哪个环节出错率最高？
哪个环节AI表现最差？
哪个环节最容易被人忽略？

第二，分析原因

针对发现的问题，分析根本原因：

是提示词不够好？
是流程设计不合理？
是AI能力不足？
是边界定义不清？

第三，制定方案

针对原因，制定优化方案：

优化提示词
调整流程
更换工具
重新定义边界

第四，实施验证

实施优化方案，然后运行一周，验证效果：

时间是否缩短？
错误率是否降低？
质量是否提升？

曹老师实践

我有一个"技术方案撰写"工作流，用了一年多，迭代了十几个版本。

第一版（初始版）：

需求描述 → AI生成方案 → 我直接用

问题：方案太泛，不贴合实际

第二版（加入校验）：

需求描述 → AI生成方案 → 我review → 修改 → 用

问题：review时间长，每次至少1小时

第三版（优化提示词）：

需求描述 + 上下文信息 → AI生成方案 → 我快速检查 → 用

改进：给AI更多上下文，让它理解更准确，我的检查时间缩短到20分钟

第四版（增加反馈）：

需求描述 + 上下文 + 历史问题 → AI生成方案 → 我检查 + 记录问题 → 用

改进：把之前犯过的错告诉AI，避免重复

第五版（拆分任务）：

需求描述 → AI生成架构图 + 我补充细节 → AI生成风险分析 + 我调整 → AI生成接口设计 + 我确认 → 整合方案

改进：把一个大任务拆成多个小任务，AI专注做好每个小任务，我的精力集中在关键环节

第六版（当前版本）：

需求描述 + 上下文 + 历史问题 + 团队规范 → AI生成方案初稿（分模块） → 并行：AI自检 + 我快速扫描 → 针对问题优化 → 业务方确认 → 定稿

效果：从需求到定稿，从原来的4小时缩短到1.5小时，质量还提升了

迭代关键点：

1. 每周一个点：不要试图一次优化所有问题，每周选一个重点就好

2. 数据说话：记录每次迭代的数据（时间、错误率、满意度），用数据评估效果

3. 保留历史：每次迭代后保留旧版本，如果新版本不行可以回退

4. 接受不完美：不是每次迭代都会成功，失败也是学习的一部分

金句：工作流不是一次建成的，而是迭代出来的。

常见误区

误区一：迭代没有明确目标

有些人每周都在改工作流，但不知道要改什么，改了也不知道效果好不好。这样迭代效率很低。

迭代必须有明确目标：这次要缩短时间？还是要提高质量？还是要降低错误率？目标清晰，迭代才有方向。

误区二：追求大改动，忽略小优化

有些人总觉得要"大干一场"，把整个工作流推翻重来。但大改动风险高、成本大，反而不如频繁的小优化。

我的建议是：每周一个15分钟的小优化，比每月一次4小时的大改动更有效。

行动清单：

[ ] 列出你工作流的所有环节
[ ] 记录本周每个环节的运行数据（时间、错误率、满意度）
[ ] 找出最需要优化的1个环节
[ ] 分析原因，制定优化方案
[ ] 下周实施优化，并验证效果
[ ] 保留优化前后的对比数据

第六步：从效率提升到能力升级

是什么

前面五步，讲的都是"怎么用AI提高效率"。但效率提升只是第一步，真正的价值在于能力升级——从执行者变成决策者，从做对事情变成做对的事情。

AI能帮你做很多重复性、探索性的工作，这样你就有更多时间思考战略、做决策、创新。这才是AI时代的核心竞争力。

怎么做

从效率到能力的升级，有三个关键点：

第一，用AI的时间做更重要的事

如果你用AI把原来需要8小时的工作压缩到2小时，省下的6小时用来干什么？刷手机？加班？

正确的做法是：用省下的时间做那些AI做不了、但更有价值的事。比如：

深入理解业务需求
思考技术架构的长期规划
指导团队成员成长
探索新的技术方向
建立更好的协作机制

第二，让AI成为你的"第二大脑"

不仅用AI做执行工作，还用它做思考辅助。比如：

让AI帮你 brainstorm 新的想法
让AI帮你分析复杂问题的多个角度
让AI帮你找出决策中的盲点
让AI帮你预判潜在风险

第三，把个人能力转化为团队资产

你掌握的AI工作流，不应该只是你一个人的秘密武器。把它标准化、文档化，让团队成员都能用，这样整个团队的效率和能力都会提升。

曹老师实践

我自己的转型，是从"代码review机器人"到"技术决策者"开始的。

之前的状态：

作为技术负责人，我大部分时间都在做review：review代码、review方案、review文档。每周至少花20小时在这些事情上。虽然保证了质量，但几乎没有时间思考战略。

引入AI后的状态：

我建立了半自动化的review工作流，AI做初步review，我重点审核关键问题。这样，review时间从20小时缩短到5小时。

省下来的15小时，我做了什么？

1. 深入理解业务：每周跟产品经理、运营聊一次，了解业务方向和痛点，提前规划技术方案

2. 培养团队：每周给团队做一次技术分享，把我的经验和思考传递给他们，也听取他们的想法

3. 探索新技术：定期调研新技术趋势，评估哪些值得尝试，哪些是噪音

4. 优化流程：持续优化团队协作机制，减少摩擦，提高效率

结果呢？

半年后，我们团队的表现：

项目交付速度提升40%
线上故障率降低60%
团队成员的满意度提升（因为不用频繁等我的review）
我的成就感也提升了（从被动review变成了主动规划）

关键转变：

以前我觉得，技术负责人的价值就是"保证质量"。现在我明白，真正的价值是"指明方向"——不仅要把事情做对，还要做对的事情。

AI帮我完成了"做对事情"的执行部分，我就能专注于"做对的事情"的决策部分。这才是AI时代技术负责人该有的样子。

金句：AI能帮你省时间，但省下的时间用来做什么，才是你的核心竞争力。

常见误区

误区一：效率提升后只是做更多同样的事

有些人用AI省下了时间，但用省下的时间做更多同样的事情。比如原来review 10个项目，现在review 20个项目。结果是，你更忙了，但没有获得能力升级。

效率提升的目的是让你有时间做更重要的事，而不是做更多的事。

误区二：认为决策能力是天生的，学不会

有人说"我不是做决策的料"、"我只会写代码"。但决策能力是可以培养的，关键是有机会练习。

AI帮你省下的时间，就是你练习决策能力的机会。不要浪费。

行动清单：

[ ] 计算一下：用AI后，你每周能省下多少时间？
[ ] 列出3件"AI做不了但你认为有价值"的事
[ ] 从这3件事中选1件，下周用省下的时间去做
[ ] 思考：你的AI工作流，如何让团队也能用？
[ ] 把你的工作流整理成文档，分享给至少1个同事

结语：行动的勇气

写到这，我想起小王上周跟我说的最后一句话。

他说："师父，我现在明白你常说的那句话了——AI再强，也只是工具。真正的竞争力，不是会用AI，而是知道AI该用在哪儿，以及用AI省下的时间用来做什么。"

我笑了，说："你现在懂了。但懂了还不够，还要做。很多人懂了道理，但永远不会行动。"

他点点头："我会的。我已经在规划下一步了。"

屏幕上的代码还在运行，AI正在帮他做下一次review。小王已经从一个焦虑的程序员，变成了一个会驾驭AI工具的技术骨干。

你呢？

这篇文章看了六个步骤，每个步骤都有行动清单。如果看完就关了，那跟没看没区别。但如果从今天开始行动，每天做一点点，一个月后，你就会发现：AI不是洪水猛兽，也不是救命稻草，它就是一件趁手的工具，能帮你做更多、更难、更有价值的事。

不要等完美了再开始，不要怕失败，不要找借口。

现在就动手。

金句：未来的竞争，不是人与AI的竞争，而是会用AI的人和不会用AI的人的竞争。

你现在，站在哪一边？