进阶版写作规范
进阶版文章面向已经读过基础版、并希望把 AI 能力落到真实产品和工程系统里的读者。文章必须以问题场景为起点，避免直接从技术名词出发。
每篇文章都要帮助读者完成一次工程判断：这个业务问题是否需要 AI，是否只需要简单 prompt，还是需要进入可评估、可观测、可控的工程方案。
统一模板
每篇专题文章统一使用五段式结构。具体文章编写要按“提出问题、分析问题、列举方案、决策判断、结论收束”的思路走：
- 提出问题
- 分析问题
- 列举方案
- 决策判断
- 结论收束
五段式不是减少工程判断，而是把原有的场景、问题类型、风险收益、方案阶梯、选型表、反模式和工程清单归入同一条判断链路：先说明问题，再拆解约束，然后列出可选路径，最后做出选择并给出上线检查。
1. 提出问题
先写清楚具体业务场景，不要直接写“本文介绍 RAG”“本文介绍 Agent”。
必须回答：
- 谁在使用这个能力？
- 发生在什么业务流程里？
- 输入是什么，来自哪里？
- 期望输出是什么，谁会消费输出？
- 使用频率和并发规模如何？
- 现在没有 AI 时，人工或传统系统怎么处理？
- 哪些样本最常见，哪些样本最容易失败？
推荐写法：
- 用 1-3 段文字交代业务流程、当前做法和痛点。
- 必要时补一张小表，列出使用者、输入、输出、频率、失败代价。
- 不在这一段展开技术方案，只提出问题和约束。
示例写法：
在 B2B SaaS 客服后台，客服每天需要阅读用户提交的长工单、判断问题类型、检索内部知识库并生成回复草稿。当前人工处理平均需要 6 分钟，主要瓶颈不在打字，而在定位知识、判断上下文和避免误答。
场景部分要让读者看见真实约束：时间、成本、权限、数据质量、用户预期和失败代价。
2. 分析问题
把业务问题拆成 AI 任务类型，并判断风险和收益。一个场景通常包含多个问题类型，文章需要逐一标明。
常见问题类型：
- 分类：判断意图、风险等级、工单类型、用户阶段。
- 抽取：从文本、图片、文档中提取字段和结构化信息。
- 改写：润色、压缩、翻译、风格调整、格式转换。
- 生成：生成回复、摘要、报告、代码、运营文案或方案草稿。
- 检索：从文档、知识库、数据库或历史记录中找到证据。
- 判断：基于规则、证据或上下文给出建议和理由。
- 规划：拆解多步骤任务，安排执行顺序。
- 执行：调用工具、修改数据、发起流程或触发外部系统。
必须说明：
- 哪些部分适合交给模型？
- 哪些部分应该由规则、数据库查询或传统程序处理？
- 哪些部分必须保留人工确认？
- 输出是否需要结构化、可追溯或可审计？
在写方案前，先判断收益是否值得覆盖成本和风险。
收益维度：
- 节省人工时间。
- 降低重复劳动。
- 提升响应速度。
- 提高信息覆盖率。
- 减少人工遗漏。
- 改善用户体验。
- 扩展原本无法规模化的长尾服务。
风险维度：
- 错误输出造成业务损失。
- 幻觉、误引用或证据不足。
- 泄露隐私、商业机密或越权数据。
- 执行错误操作。
- 成本不可控。
- 延迟影响核心流程。
- 质量不可评估，无法持续迭代。
这一节必须写出失败代价。低风险场景可以接受人工复核和轻量校验，高风险场景必须设计权限、评估、审计、回滚和人工确认。
推荐放法：
- 先用清单列出任务拆解，避免把整个业务问题笼统称为“生成”或“Agent”。
- 再用 1 张风险/收益表说明为什么值得做、哪里不能完全自动化。
- 表格可以使用以下结构：
3. 列举方案
方案必须从简单到复杂逐级展开，不能默认使用最重的架构。
推荐阶梯：
- 不用 AI：规则、搜索、表单、模板、数据库查询是否已经足够。
- 简单 prompt：固定输入、固定输出、低风险、人工可复核时，使用 prompt 模板即可。
- Prompt + Schema：需要稳定字段、业务校验、重试和错误提示时，引入结构化输出。
- Prompt + Context：需要用户状态、业务对象、历史记录或少量动态信息时，引入上下文工程。
- RAG / Search：需要私有知识、引用来源、知识更新和证据追溯时，引入检索。
- Tool Calling：需要读取系统数据、调用接口或执行动作时，引入工具边界和权限控制。
- Workflow：需要多个稳定步骤、状态流转、异常处理和可观测性时，引入工作流。
- Agent：只有当任务路径高度动态、需要模型自主选择步骤，并且有充分观测、权限和回滚机制时，才考虑更开放的 agent。
- Eval + Ops：一旦进入生产环境，必须补齐评估、监控、成本控制、版本管理和反馈闭环。
每篇文章必须明确说明：
- 什么时候简单 prompt 足够。
- 什么时候 prompt 不再足够。
- 升级到下一层方案会增加什么能力。
- 升级到下一层方案会增加什么成本。
推荐放法：
- 用“方案阶梯”作为本段主体。
- 每一层方案都写清适用条件、增加的能力和新增成本。
- 不必每篇文章都完整展开 9 层，但必须说明为什么没有选择更重的层级。
- 如果文章主题本身是某一层方案，例如 RAG、Tool Calling 或 Workflow，也要从更轻方案写起，证明升级必要性。
4. 决策判断
每篇文章都要提供一张选型表，用于把业务约束和技术方案对应起来。
推荐表头：
选型表不追求覆盖所有技术名词，而要帮助读者理解取舍。
本段必须给出明确判断，而不只是罗列方案。读者读完后应该知道：在什么条件下选择简单 prompt，在什么条件下升级到结构化输出、RAG、工具调用、工作流或 Agent。
决策判断还必须列出常见错误做法，并解释为什么会失败。
常见反模式：
- 从技术出发，而不是从业务问题出发。
- 看到知识库就直接上向量数据库。
- 看到多步骤任务就直接做 Agent。
- 用更长 prompt 掩盖数据、权限、评估或流程问题。
- 没有 schema，却要求模型输出稳定业务数据。
- 没有引用来源，却把答案当事实使用。
- 没有人工确认，却让模型执行高风险操作。
- 没有评估集，却凭主观感觉判断质量。
- 没有成本归因，却在核心链路无限增加上下文和模型调用。
- 没有日志和回放，线上出错后无法复盘。
推荐放法：
- 先放选型表，再写 2-5 条决策理由。
- 反模式可以放在选型表后，作为“不这样做”的边界说明。
- 反模式要对应前文场景里的失败样本，不要写成通用口号。
反模式部分要写得具体，最好能对应到前文场景里的失败样本。
5. 结论收束
文章结尾必须提供工程清单。清单不是泛泛总结，而是上线前检查项。
建议包含：
- 场景边界：目标用户、业务流程、输入输出是否明确。
- 质量标准：什么是好结果、可接受结果和必须拦截的坏结果。
- 数据来源：输入、上下文、知识库、工具返回值是否可信。
- Prompt 资产：模板、变量、版本、变更记录是否可管理。
- 结构化输出：schema、校验、重试、降级是否完整。
- 权限控制：用户能看到什么、模型能访问什么、工具能执行什么。
- 人工确认：哪些动作必须确认，确认界面展示哪些依据。
- 可观测性：记录 prompt、上下文摘要、模型、参数、工具调用和错误。
- 评估体系：是否有样本集、回归测试、线上反馈和人工标注机制。
- 成本延迟：是否有预算、缓存、降级、模型路由和超时策略。
- 安全合规：是否处理注入、越权、敏感信息、日志脱敏和审计。
- 回滚恢复：错误输出或错误操作发生后如何撤销和复盘。
工程清单应该让读者能拿去做设计评审，而不只是阅读后的概念回顾。
结论收束必须回答：
- 本文最终推荐什么方案？
- 这个方案成立的前提是什么？
- 哪些情况应该降级到更简单方案？
- 哪些情况必须升级工程复杂度？
- 上线前至少要补齐哪些检查项？
推荐放法：
- 用 1-2 段文字收束主要判断，不要重新介绍技术概念。
- 紧接着放工程清单，作为设计评审和上线前检查项。
- 可以用“最低可上线版本”和“继续演进方向”各列 3-5 条，但不要把结论写成愿景口号。
写作风格
进阶版文章保持工程化、克制、具体。
- 少用“智能化”“赋能”“一键生成”这类空泛词。
- 多写业务流程、失败样本、边界条件和取舍理由。
- 不把复杂方案包装成默认正确。
- 不为了展示技术而引入技术。
- 每个技术选择都要回到场景、风险、收益和成本。
文章最终要让读者具备一种判断力：能先说清楚问题，再选择方案；能先证明简单方案不够，再升级工程复杂度。