13. 产品流程
不是「又一个通用 Agent」：针对写作任务的产品流程设计
进入最后一个板块「嵌入垂直业务」。前面十二篇，我们把 12 个机制从引擎一路拆到编排与分工，零件全见过了。但零件本身不是产品。这一篇，就讲我怎么把这些标准的 Agent 能力，逐个「桥接」到真实的写作任务上，让它不再是「又一个通用 Agent」
🪧 12 个零件，怎么装成一台用户能开的车
前面十二篇，像是在拆解一台发动机一样，把 Agent 的 12 个零件挨个摊开看。但诚实地说，用户根本不关心这些零件，他们也不应该
一个专心写作的人，为什么要在乎你后台跑的是 Loop 还是 Hook、派没派 Subagent 呢？他关心的只有一件事，我能不能借你，更快、更贴合地把脑子里那点想法，落成一篇像样的文章。 零件再精密，装不出一台能开的车，对他而言就是零
所以最后这个板块，讲的就是怎么「装车」。而这一篇的核心动作，可以比喻为搭桥：一头是「标准、通用的 Agent 能力」，另一头是「写作这个具体业务的真实需求」，我要在两头之间把桥搭起来。这一篇，我挑了四座最关键的桥，一座座讲
🧭 地基：Flow Design，一次任务只围绕「一个作品」打磨
在搭这四座桥之前，得先打好一块地基：Flow Design。第 7 篇讲产出契约时，曾经提起过它，这里正式说清楚
用一句话提炼它的内核：一次写作任务，自始至终只围绕「一个作品」在打磨。 你丢进来的底稿、附件，你敲的 / 命令或指令，全是输入；它们汇进来，最终都指向同一件事，就是把这一个作品，建得更好、改得更顺
这个「只有一个作品」的设定，是产品设计的原点，后续的流程和功能都围绕它而建。它给了用户一个稳定的锚：不管你这一下用的是润色命令、还是粘了段素材、还是随口说句话，你心里都清楚，这些都作用在「我这一篇」上，不会平白冒出第二篇、第三篇让你手忙脚乱。顺带一提，这个作品在后台叫 draft.md，但这个名字从不对用户露脸，对话里一律只说「你的作品」（内部术语不外露，只对用户说人话）
这个地基铺平了，才能开始搭桥
🌉 第一座桥：上下文注入顺序，把一堆输入喂成模型读得懂的次序
第一座桥，藏在一个很不起眼的地方：顺序
标准的 Agent 跟模型对话，一次只能递过去「一条 user message」。可写作业务里，用户这一次交互，能塞进来的东西性质五花八门，包括：有关这类题材写作的方法论、这次使用的协作模式、用户精心准备的写作底稿、从作品里划选的引用、上传的参考附件、还有用户最后手敲的那句指令。六种性质不同的输入，都得塞进这一条 user message 里，先后次序，就大有讲究
我定的顺序是这样的，每次上下文拼装都严格遵循：
这个次序的设计，背后是我自己总结的语义优先级：底稿素材先于内部参考，内部参考先于外部参考，外部参考先于指令。 说人话就是：先让模型把「原材料」都吸收了，最后再告诉它「这次要拿这些材料干什么」。这和人的思考习惯是一样的：我们一般都会先看完手头的资料，再决定动笔怎么写，而不是反过来
再举个例子，假设你上传了一份厚实的产品文档，同时敲了句「帮我撰写一份入门科普类推广文章」。这里，产品文档是「外部参考」（附件），「撰写...文章」是「指令」。按目前设计的顺序，文档在前、指令在后。这么一排，模型会先把产品文档当资料吸收，最后才接到「撰写推广文章」这个指令。可要是顺序反了，指令在前、文档在后，模型可能读完那篇长长的产品文档后，把核心任务忘在了脑后，容易跑偏。同样一堆输入，仅仅是排列的次序不同，出来的结果就可能天差地别。这道桥，搭的就是「输入的次序」
🌟 第二座桥（重点）：画像闭环，「越写越懂你」到底怎么转
第二座桥，是这个产品的灵魂，也是最需要细讲的一块。前面所有机制加起来，是让 Agent「会写」；而这座桥，是让它跨越单次写作的围栏，真正做到「越写越懂你」
用户对 AI 成稿的「二次编辑」，在我看来，是最高质量的风格信号。 AI 写完，你动手改了哪几个词、调了哪句的语序和表达、删减了哪段，这些改动，比任何问卷都更真实地暴露了你的偏好
整个实现，拆成 4 步来讲：
1）采集：EditSession，像用 Word 一样，一次「坐下来改」算一轮
怎么定义「一次编辑」？这是第一个坑。最初我按「每次保存」算，结果全是问题。重构后，才引入了一个更贴合真实行为的概念，EditSession。
可以作这样的类比：你打开一个 Word 文档，改了半天，最后关掉。这「半天」，就是一次 EditSession。中间你按了多少次 Ctrl+S 都无所谓，那都是这一次会话的一部分；关掉文档，才算这一轮结束。落到 SmartWriter 里：点「编辑」进入编辑态是开始，中间的自动保存只是默默累积、不单独结算，点「退出编辑」（或切到别的任务、关掉页面）才是结束。一次会话，最终只沉淀一条编辑记录
这个概念确定下来后，三个关键设计也跟着定了：
- diff 的基准，固定为「会话开始时的那个 AI 版本」。 编辑期间，就算 AI 版本在别处更新了，我这次比对的基准也不动。否则基准一漂移，算出来的「你改了什么」就全乱了
- 「改动是否足够大」的阈值，作用于「跨会话累积」的改动，而不是单次。 这是重构修掉的一个大硬伤：以前阈值卡在「单次保存」上，一个用户如果习惯小改多次，每次都不到阈值，那他的偏好就被永远漏掉了。改成跨会话累积后，你今天改一点、明天改一点，攒够了样本照样能被捕捉到
- diff 不在你退出编辑的当下就急着算，而是推迟到「合适的时机」。 自动保存只管累积，真正的比对计算，交给后台（启动时、定期低频扫描、或你主动点「更新画像」）去做。既省算力，也不打扰你写作
还有一条产品约束值得一提：编辑和对话，是互斥的。 你在编辑态时，AI 不动你的稿子；你不编辑时，AI 才能动。这样就永远不会出现「你和 AI 同时改同一篇」的并发混乱，diff 基准在整个会话期间能保持稳定
🔧 避坑 · 重构前，这条采集链路埋着三个硬伤
这座桥我搭了不止一版。回头看重构前的老版本，有三个硬伤，任何一个都能让「越写越懂你」失灵：
1）阈值卡在「单次保存」上：习惯小改多次的用户，每一次都不到阈值，偏好被永久漏采。（正解：改为跨会话累积） 2）AI 归档会「吃掉」用户的改动：AI 每写完一轮会归档一个版本，老逻辑归档时机没保护好，会把用户还没结算的手动改动，误当成 AI 自己写的，信号直接被污染。（正解：归档前先保护用户未结算的改动 + 编辑对话互斥） 3）分析只在后端重启时才触发：攒够了也得等我重启后端才跑，形同虚设。（正解：把触发绑到启动 / 定期扫描 / 用户点击三个时机上）
「采集用户行为信号」这件事，魔鬼细节全在边界情况里，小改多次、并发改动、触发时机，其中哪一个没考虑到，采上来的就是一堆脏数据，喂给画像只会越喂越歪
2）分析：单轨批处理，攒几篇一起看，才看得出「稳定偏好」
采上来的编辑信号，不即时回写，而是攒着，攒够一批，统一跑一次分析（称之为单轨批处理）
为什么不即时、要攒批？因为单看一篇的改动，是分不清「稳定偏好」和「一次性噪声」的。 你这次把「非常」改成「特别」，可能是真偏好，也可能只是这句话顺手。手滑、临时改动、纯粹的事实订正，这些噪声混在里面。只有攒多几篇一起看，那些反复出现的改动模式（比如你总把某类词换掉、总爱把长句拆短），才会浮出水面，那才是值得进画像的稳定信号
这个分析，是一个彻头彻尾的带外流程，它不发生在你和 AI 写作的那个工具循环里，而是在后台静默跑。而且它不是攒够了就自动跑：只有你主动点「更新画像」时，分析才真正触发。启动时和定期扫描只管累积 diff、更新进度条，不跑分析。这里的设计意图是：画像更新是「花 token、产出建议」的动作，该由用户掌控时机，不该后台偷跑。它要产出的，是「可供程序消费的结构化结论」，最终会变成前端一次确定性的交互：你只管采纳或驳回
3）人工 review：画像不自动回写，一条条先让你点头
分析出来的东西，永远只是「建议」，绝不由代码自动写进你的画像。 它必须经过你的人工审阅，一条一条地，你点「接受」或「拒绝」
为什么要如此谨慎呢？因为画像是你写作的「灵魂」，污染它的代价太大了。 一个被脏数据污染的画像，会让 AI 越写越「不像你」，那这个产品的立身之本就塌了。宁可每一批都多问你一步，也不赌那一下自动回写的准确率。这道「人工 review」，就是给画像这个核心资产添加的一道保险栓
4）reject 记忆：你否决过的，我都记住，下次不再拿类似的烦你
你审阅时的两种操作，我会区别对待：
- 你点「接受」的：写进画像，并记一笔变更日志
- 你点「拒绝」的：进一个专门的 reject 记忆（按内容去重、带权重衰减）
关键在于对「拒绝」的态度。一个「拒绝」信号，其实比「接受」更强烈，因为它是你明确表达的「我不要这个」。 因此要把它郑重记下来，下次后台再做分析时，会把这些你否决过的偏好注入进去，让它避免再产出类似的建议。更进一层，那些被否决的编辑模式，还会被提炼成结构性约束。不再光靠 prompt 提醒，还可以作为硬规则在产出后过滤，从源头堵住类似建议。而且用户拒绝时还可以标注原因（「这不是画风，是内容修订」「我不同意这个改法」），这些原因会分组注入下次分析，让模型从你的拒绝模式中学习，而不是每次都换个说法重新提一遍
这一下，产品的「懂你」就更立体了：它不只记着你喜欢什么，更记着你明确讨厌什么。 一个懂你且贴心的协作者，不正是这样吗？他不会拿你上次否掉的方案，换个说法再提一遍
把这四步合起来，就是「越写越懂你」的全貌：
🌉 第三座桥：任务生命周期，归档与删除的两层设计
第三座桥很朴实，但缺了它，产品长期用起来就不顺手：任务会不断累积，得让用户能整理
为此，我做了两层处理：
- 归档（软删除）：暂时不看的任务收起来，从默认列表隐藏，但底层的对话记录和工作目录都留着，随时能恢复
- 删除（硬清除）：确定不要了，彻底清掉对话和目录，不可逆，删前二次确认
只给「删除」，用户会因为「怕误删」而不敢清理，任务越囤越多；只给「归档」，又永远释放不了磁盘和心理负担。 两层叠起来，正好覆盖「先归档收起来观察 → 确定没用了再删掉」这条最自然的整理动线
这里插一句有点较真的工程原则：内存里的任务状态是运行时的真相，磁盘上的记录是重启后重建的快照，我得守住一个不变量，「内存里存在，磁盘上就一定存在」。所以删除的顺序钉得死死的，先清磁盘、再从内存里移除，绝不能反过来（万一中间崩溃，会留下「内存没了、磁盘还在」的孤儿）。启动时还有一道自愈机制：扫一遍，把那些对话记录已经损坏的任务自动归档掉。这些细节用户永远看不到，但它们是产品「不出诡异 bug」的底子
📊 第四座桥：成功指标，怎么证明它「真的有用」
最后一座桥，搭向一个做产品最容易自嗨、也最该冷静的地方：凭什么说这产品有用？ 我定了三条可观察的指标：
- S1 · 跑通闭环（能力验收）：画像注入 → 多轮可打断 → 命令激活 → plan 规划 → 终检 → hook 回写画像，每一个机制都端到端可演示。这是「能力到位了」的底线
- S2 · 二次编辑字数占比（提效验收）：你在 AI 成稿基础上改动的字数，占成稿总字数的比例。这个比例越低，说明 AI 一次产出越贴合你、提效越明显。 这是我衡量「真提效」的口径
- S3 · 画像更新建议质量自评分（越写越懂验收）：你处理完一批画像建议后，给「这批建议有没有命中我的真实偏好」打个 1 到 5 星，观察这个分数随着批次上升的趋势。趋势向上，就证明「越写越懂你」不是句空话
S2 和 S3 的数据，根本不用另外埋点去采，它们就长在画像闭环里。 S2 要的「你改了多少字」，正是第二座桥「采集」环节算 diff 时顺手得到的；S3 要的「建议命不命中」，正是「人工 review」环节你点接受 / 拒绝时自然产生的。一条闭环，既让产品「越写越懂你」，又顺手把「证明它真的有用」的度量给采了
⚖️ 垂直落点：不做「又一个通用 Agent」的 Copycat
到这儿，把这四座桥连起来，完整地看一下：
⚖️ 取舍现场 · 通用 Agent 与垂直 Agent，差在哪一层
标准 Agent 能力 "偷懒"的用法 SmartWriter 怎么做 一条 user message 把用户输入原样丢进去 按语义优先级排 6 类输入的注入顺序 记忆 记点事实、聊天上下文 画像闭环：采集编辑 → 去噪 → 人工 review → reject 记忆 会话 / 任务 用完即走 归档 + 删除两层生命周期 工具采数 无 顺手采出 S2 / S3 成功指标
一个通用的聊天助手，是一个什么都能聊、但不长在任何业务里的对话框。而垂直 Agent 的全部功夫，就在于把每一个标准能力，都结结实实地桥到一个具体的业务需求上。这一篇讲的 Flow Design、注入顺序、画像闭环、生命周期、成功指标，没有一样是 SDK 开箱就提供的，需要站在「标准能力」和「真实业务」这两头之间，一根根搭起来。搭桥的密度和用心，就是不让它沦为「又一个通用 Agent」的关键
好，产品流程这条业务动线，就讲完了。这一整篇，讲的都是「后台怎么运转」。可用户真正用手触碰的，从来不是这些流程，而是一个页面、一个输入框、一份稿子。后台再精妙的 Agent 内心戏，怎么翻译成技术小白也能一眼看懂、用起来很顺手的界面？
这是全专栏最后一篇、也是「最后一公里」的事：UI/UX 的小巧思集合。下一篇，咱们继续聊