能力主线：工具使用、方案设计与业务拆解

1. 核对文章后的结论

用户的理解抓住了主线：认识 AI 能力、理解设计方法、实际使用工具，再把这些能力对应到现有业务问题。

文章还强调生产级项目的全貌，包括数据、评测、工程接入、运行观察、成本，以及与现有组织和流程协同。因此完整主线应补上交付验证和持续改进。

推荐按下面的顺序实践，并反复循环：

认识能力 → 动手体验 → 拆解业务 → 设计组合 → 接入交付 → 验证改进。

这是为本学习计划整理的结构，不是作者 L1–L5 框架的定义。文章提到 L1–L5，但所读正文没有给出其具体层级。

2. 分清三层，避免把所有名词叫作工具

层次	内容	要建立的能力
方法与架构	Prompt、Context、Workflow、Agent、RAG	解释它解决什么问题，边界是什么
产品与平台	对话助手、流程平台、知识库平台、编程助手等	会配置、操作、看运行过程、定位失败
业务方案	面向用户，把数据、流程、工具、界面与人工协作组合起来	能交付并证明它解决了具体问题

AI Coding 是一种应用方向和开发方式，具体编程助手是实现它的工具。Workflow、Agent 和 RAG 可以在同一个平台或同一个业务方案中共存。

文章列举 Coze、Dify、FastGPT、n8n 等平台，是为了让人理解应用实践。本计划不据此断言它们当前的功能、价格或优劣。实际选择时查官方文档，确认所需功能、接入方式和数据边界。

3. 六项能力及学习产出

能力	应能回答的问题	产出
认识	这类应用能做什么，什么时候会失败？	应用分类与产品拆解卡
使用	能否独立跑完任务，查看输入输出并修改配置？	四类小实验及失败记录
业务拆解	哪些步骤耗时，依赖什么资料和判断？	当前业务流程与步骤表
设计	每一步交给规则、模型、工具还是人？	四张设计卡与选择理由
集成	怎么接数据、界面、权限和已有系统？	可完整使用的最小产品
验证改进	比以前好在哪里，失败后怎样改？	对照结果、反馈与回归记录

业务拆解不能推迟到所有工具都学完以后。用几个小实验建立手感后，就应拿一个熟悉业务反复练习。

4. 先做四类工具实验

选择少量能够合法访问、预算可控的工具即可。能用一个平台完成多项实验，就不必为了覆盖品牌再学另一个。

每项实验约一个两小时学习时段；遇到账号、部署或费用障碍时缩小目标，不把配置环境变成整周主线。小实验先采用公开或模拟资料。

实验	最小任务	需要观察什么	验收
AI Coding	修改现有 React 项目的一项小功能	上下文、改动范围、验证过程	能解释代码并处理失败
Workflow	反馈输入 → 分类 → 不同分支生成回复草稿	数据传递、条件分支、失败节点	修改分支后能解释结果变化
RAG	导入少量说明文档，问五个问题，其中一个无答案	找到的段落、引用和缺失信息处理	能检查答案是否被资料支持
Agent	给两个只读工具，让模型根据任务选择或继续查询	选了哪个工具、参数、停止原因	能与固定 Workflow 比较，不允许无限循环

如果工具不展示检索段落或执行记录，这本身就是选型时需要记录的可观测性限制。

工具使用的合格标准是能够更换输入、调整步骤并定位问题，不是照着视频复现同一条成功路径。

5. 四张设计卡：分别在设计什么

Prompt：单次任务的工作要求

• 目标：本次调用完成什么？
• 输入：有哪些内容，哪些字段可能缺失？
• 约束：必须满足什么，不能自行决定什么？
• 输出：结果格式、缺信息时的行为。
• 示例：成功与失败分别是什么样？
• 验证：如何判断内容正确，而不只是格式正确？

练习：让模型从客服消息中提取问题类型和缺失信息，不允许编造订单号。

Context：本次判断依据如何组织

• 需要用户输入、历史、资料、偏好或工具结果中的哪些内容？
• 每项信息的来源、时效和权限是什么？
• 哪些信息固定提供，哪些需要时检索？
• 长度不足时保留什么，摘要会损失哪些细节？
• 资料互相矛盾或缺失时怎样处理？

练习：同一个客服问题分别提供无资料、相关资料和混杂资料，记录差异。Context 的设计不只是把 Prompt 写得更长。

Workflow：步骤、分支与状态

• 什么触发流程？
• 每一步输入输出是什么？
• 哪些步骤确定执行，哪些由条件决定？
• 人工确认在哪里？
• 出错后重试、跳过、回退还是转人工？
• 重复提交是否造成重复业务动作？

练习：画出分类、查询、起草和确认四个步骤，并补上查不到订单的分支。

Agent：自主行动的边界

• 目标和完成条件是什么？
• 为什么预设流程不够用？
• 模型能选择什么工具，哪些动作不允许？
• 它怎样从工具结果判断成功与否？
• 最大步骤、时间或费用是多少？
• 什么情况下停止或交给人？

练习：让助手在查询结果不足时选择另一资料源。若固定流程同样有效，记录无需 Agent 的结论。

6. 怎样拆现有业务

先画当前流程，再逐步填写下面的表，不要先把所有步骤改成 AI 节点。

字段	要说明什么
步骤与责任人	谁在什么时机做什么
输入与来源	数据在哪里，能否访问，质量如何
当前动作与输出	人或程序具体做了哪些事
规则与业务经验	哪些规则能写清，哪些依赖经验
例外	缺信息、冲突、失败时怎样处理
现状基准	频率、时间、返工、遗漏
候选实现	普通代码、模型、检索、Workflow、Agent、人工
验证与兜底	怎么判断正确，出错谁接手

业务经验（Know-how）要尽可能转成规则、案例、决策表和评分标准。若业务专家自己还无法定义“好结果”，先澄清标准，而不是不断修改提示词。

7. 例子：售后问题处理

以下是教学示例，不是已经验证的业务收益，也不是要求执行真实退款。

业务步骤	更合适的候选方法	选择理由
识别消息主题	模型分类，简单场景也可用规则	自然语言表达多样
检查登录与身份	普通后端鉴权	身份不能由语言模型推测
查询订单状态	受控业务接口	实时数据应来自业务系统
查找售后政策	搜索或 RAG	需要有来源、可更新的资料
判断明确的申请条件	业务规则或决策表	已确定的规则适合可审计执行
起草解释	模型 + 当前查询结果	将确定信息组织成易读回复
判断特殊争议	人工处理	需要授权与业务判断
执行实际退款	授权后由交易系统执行	需要确认、权限与幂等保障

整体可以由 Workflow 组织。只有调查路径确实难以预先确定时，才考虑增加 Agent。

这个例子体现的目标能力是：看到一项业务，知道哪些问题属于语言理解，哪些属于资料、规则、系统接口和人工决策。

8. 从工具原型到代码实现

先用现成工具验证核心任务，再决定哪些部分保留平台实现、哪些通过接口集成、哪些需要自行开发。

做选择时检查：业务系统接入、权限、交互定制、执行记录、版本管理、测试方式、运行成本与维护成本。不要默认低代码只能做演示，也不要默认所有流程都适合放在平台里。

你的 React / TS / Node.js 经验主要用于把已经验证的能力接进真实产品，并补齐工具不能满足的部分。

9. 验证与数据反馈闭环

完整循环：收集失败和人工修正 → 去除敏感信息 → 人工审核 → 分类归因 → 加入适当的评测集合 → 调整资料、Prompt、流程或代码 → 回归验证 → 受控发布。

不是所有失败都需要换模型：

• 资料缺失：补资料或改业务流程。
• 规则不清：请业务负责人明确标准。
• 检索遗漏：检查文档、切分和检索。
• 输出误读：改上下文或表达，检查交互。
• 写入失败：修接口、权限或幂等。

不要把用户反馈自动当成正确标签，也不要把每次调整使用过的样例继续视为独立验收集。这里的反馈闭环不等于自动训练模型。

10. 对原学习计划的修订

保留工程、评测和贯穿项目；加强前两周的工具体验，第 3 周增加业务拆解表，第 4 周明确四张设计卡，最后增加失败样例到回归验证的闭环。

文中“底层技术没用”等表达不作为绝对结论。应用路线应按问题分配学习优先级；精确检索需要时，BM25 等技术仍可能有价值。文章中的商业推广和就业案例也不能替代自己的能力验证。