version: "1.0.0" name: 文稿写作 description: Use when 要从零写中文成稿（文章/文案/报告/演讲稿/周报/邮件/方案说明）时加载；已有成稿改稿走 polish-prose，调研报告走 deep-research。

核心流程：定读者目的 → 搭骨架 → 成文 → 自检 → 落盘

何时加载：用户只有主题、意图或散材料，要求从零写一篇文章、文案、报告、演讲稿、周报、邮件、方案说明或口播稿。 不加载：已有成稿只需修改或诊断（走 polish-prose）、需多源检索的调研报告（走 deep-research）、代码与配置（走 agent-dev-loop）、纯翻译、纯问答。

硬步骤

1. 定三件事 + 清素材：读者是谁、读完得到什么、文体是什么，三问都要有答案；素材按事实/数字/例子/引语四栏清点，缺口标出 → 判据：一句话说清给谁看、要什么效果；能推断的定合理默认，只在改变决策且查不到时用 ask_user_question 一次问全。
2. 搭骨架：写主张（≤30 字，是主张不是话题）、每条支撑都带证据、写明边界（什么情况下不成立 / 最强反对意见）；拿不出证据的支撑不进骨架 → 判据：每条支撑都有数字、时间、对象或例子。
3. 成文：按文体适配表落笔（结论位置、句长、人称、段长），边写边把证据带在支撑句上；非用户提供的事实一律标 [需补事实] → 判据：无编造的数字、引语、案例、来源，不靠生成句子凑篇幅。
4. AI 特征自检：逐项过 AI 特征表（判断/转折/比较滥用、句式重复、实词复用、空话、节间同构、段长、无据断言），写「第几段、删改什么、为什么」→ 判据：未命中写「无」，禁止只写「已检查」；文体程式与刻意重复不算特征。
5. 落盘：常规文件夹默认写入当前目录 <slug>.md；项目文件夹由用户指定路径，不自行塞进 docs/；用户要求仅对话输出则不落盘 → 判据：对话只回路径 + 主张一句 + 待补事实清单。

多份交付物才分派：多篇系列、多语版本、正文＋附录等多份可独立交付的稿子，每份一个 owner 端到端，任一份结算即补位，不排阶段接力、不做全批等待。

完成判据：成稿已落盘（或用户要求仅对话输出），AI 特征表逐项落到位置，[需补事实] 与未核实项已列明；证据=文件路径 + 档内自检记录 + 待补清单；只写「已检查」或素材不足仍开写不算完成。

文稿写作

从零产出一篇中文文稿。核心不是"写得好看"，而是先想清楚要说给谁听、要让他得到什么，再落笔。

与润色技能的边界

一篇稿子同时要求"写"和"润"时，先按本技能从零成文，再对同一份稿子做润色，不要拆成两个人各做一半。

需要展开文体细节时读 references/style-profiles.md（六种文体的松紧规则 + 正反范例）。

定三件事 + 清点素材

三件事必须都有答案：

清点素材：把用户给的材料分成四栏——事实、数字、例子、引语。逐栏看缺什么，缺口当场标出来。

追问要克制、也要准：

• 只在真正改变决策、而且项目材料里查不到时才用 ask_user_question；一次问全，不要挤牙膏式来回。
• 能推断的不要问，自己定一个合理默认，并在骨架里写明假设。
• 用户问不出来也没有信息量的（"读者画像是什么"），不要问。
• 用户已授权范围内的可逆动作直接做，不重复询问；审批与扩权只有用户入口，你没有等价工具。

出骨架

骨架格式（四行以内能写完）：

主张：<一句话，≤30 字，是主张不是话题>
支撑 1：<断言>　—— 证据：<数字 / 时间 / 对象 / 例子>
支撑 2：<断言>　—— 证据：<…>
支撑 3：<断言>　—— 证据：<…>
边界：<什么情况下这条主张不成立；或最强的反对意见是什么>

两条底线：

• 支撑句没有证据，不进骨架。 拿不出证据的支撑，要么删掉，要么降级成"待确认"并标注。不许先写断言、指望成文时再补证据——补不上就会编。
• 素材不足不靠生成句子凑篇幅。 用户说"你看着办"时可以继续写，但所有非用户提供的事实必须标 `[需补事实]`；禁止编造数字、引语、案例、来源。

支撑条数按主张实际能撑住的量来定，几条能站住就写几条，不凑数也不设固定门坎。

骨架写出来是为了给自己对齐逻辑，可以随成稿一并交给用户看，但不需要用户批准才继续。用户说"直接写"就直接成文，骨架仍要先写。

成文

文体适配表（"定三件事"里选定的文体决定这一行怎么走）：

写的过程中同步守住两条最容易破的：

1. 每个支撑句带着它的证据一起写——不要先铺逻辑再补数字。
2. `[需补事实]` 当场打上——不要留到收尾时凭印象补，那时你会不记得哪些是真材料。

AI 特征自检

按下面「核心方法论：AI 特征表」逐项过一遍，每项都要落到具体位置。

禁止只写「已检查」。 自检结果必须逐项给出「在第几段、删/改了哪几个字、为什么」。

「已检查」不是自检结果，是没自检的证据。

自检记录格式（逐个特征都要有，未命中的写「无」）：

比较的滥用：第 2–5 节都以「别国不具备」对照收尾 → 第 4 节改为直接给结论
判断的滥用：第 2、4 段末各一句「这是…」→ 删去第 4 段那句
转折的滥用：全篇 9 处转折标记，密度明显偏高 → 删去 4 处纯过渡的
句式重复：「不是…而是…」3 次 → 保留最有力的第 2 处，其余改写
句式单一：全篇以中长句为主，缺停顿 → 第 3 段加一个破折号
实词复用：「条件」11 次 → 换掉 5 处
空话：第 1 段「在当前的时代背景下」删掉后读者无损失 → 删
节间同构：5 节骨架同为「论点→证据→对照→小结」→ 第 4 节改为「数据→反例→收束」
段长分布集中：6 段均在 120–150 字 → 第 1 段压到 60 字
无据断言：2 处 → 回去找证据（见文末清单）

自检检出的问题，由你判断要不要改、怎么改；改完再交付。

检出不等于必须消除——作者刻意的呼应、排比，文体要求的程式，都可以保留。判断标准只有一条：读者能不能从这个特征认出「这是机器写的」。

产出与落盘

落盘规则（默认落盘）：

文稿技能通常用于常规文件夹，不是项目文件夹。

默认把成稿写入当前文件夹；若判定当前是项目文件夹（存在 `docs/GOAL.md` 或 `docs/design/`），则由用户指定路径，不要自行塞进 docs/。

文件名：<slug>.md，slug 用中文主题的简短写法（如 2026-09-供应链复盘.md）。用户明确说"只在对话里看"则不落盘。

结果分层：对话里只回文件路径 + 主张一句话 + [需补事实] 清单（如有），不贴全文；原始素材、逐轮自检记录留在文件或子会话里。给用户的摘要要含来源、版本、遗漏、不确定性、未完成项。

多份交付物：横向切分与滚动补位

一篇稿子由一个 owner 端到端做完。只有当一个写作任务真的产出多份可独立交付的东西（多篇系列、多语版本、正文＋附录、多个章节、多个证据包）时，才需要分派，规则如下。

横向交付合约（按产物切分，不按阶段切分）

• 切分单位是可独立交付的产物：一篇 / 一章 / 一个 module / 一个 evidence-package。
• 每份交付物由一个 owner 端到端负责：取材 → 搭骨架 → 成文 → 自检 → 修复 → 交付验收。
• 拒绝同一交付物上的阶段接力：不要"先统一做背景调查 → 再统一出设计 → 再统一审校"，也不要"计划 → 编码 → 审查"式接力——那会让每个环节都没有上下文。
• 遇到这种排法，给出横向重排建议：把按阶段分的人改成按交付物分，每人认领自己那份并负责到验收。
• 同一 owner 收尾修复自己的稿子。全局集成（总述、目录、术语一致性、跨篇口径）由 leader 与相关 owner 共同负责，不撤走前面的人、换一个没有上下文的审查员来接管后半程。

事件驱动滚动补位

• 任一份交付物结算就立即补位下一份 ready 项，不等同批其它任务完成。
• 没有全批屏障、没有整层等待；慢的一篇不阻塞其它 ready 篇目。
• 未 ready 不派发；并发满额时明确拒绝并保持 ready（CAPACITY_FULL），不排队空等，也不用一次性旁路绕开上限。

跨交付物依赖

• 依赖只允许存在于不同交付物之间，并且要求 version + requires（published-interface 或 verified-result）。
• 例：总述依赖各分篇的 verified-result（已核实的事实清单与主张）与某一版接口约定；依赖未就绪就不派发。

超时与阻塞

• 超时先判断进展与可恢复性；"状态未知 / 暂停"与"真正失败"严格分开，超时不等于失败。

阻塞处理顺序：

1. 记录确切失败、已尝试的路径、影响范围、以及此刻仍能做的事。
2. 先查已装服务、源码、现成工具、当前权限——很多阻塞在这一步就没了。
3. 能写适配器 / 接口 / 本地桥接补齐的，就补齐。
4. 局部阻塞先做其它 ready 项，并把 blocker 精确挂到受影响的交付物上。
5. 确实需要外部账号、人工决策或无法获得的资源，才标记 needs_user，并给出已尝试路径与最小下一步。

不设"试三次就结束"，也不无预算地反复重试同一个失败。权限拒绝不可绕过。

可用工具：read write edit glob grep pwsh；skill(name="myworkflow-write-prose")；lead 用 team_mission_assign（模块委托，不产生可调度项）、team_member_create、team_snapshot、team_interrupt、team_layout，不替成员写 work/plan；member 用 team_plan_submit（自己提交自己拥有的 work，planRevision CAS）、team_dispatch_authorize（授权派发）、team_plan_cancel（取消未来派发）、team_subagent_start（定向启动自己的执行者）、team_member_inbox（处理自己的事件）、team_work_verify（按验收条件核验）、team_message、team_wait、team_recover；leaf 用 team_work_report（交回结果）、team_ask_owner（只向自己的 owner 求助/回报）——team_message 对 leaf 不可用。观察与等待用 team_snapshot team_wait；停止与恢复用 team_interrupt team_recover；todo_write ask_user_question present。

核心方法论：AI 特征表

先决：文体与用途

检任何东西之前，先明确：这是什么文章、给谁看、要什么效果。

公文的程式化、学术论文的长定语、公众号的短句节奏、演讲稿的口语重复——这些写法互相冲突，而且都正当。本表所有判断以此为前提：文体允许的，就不是特征。

用法

本表是特征检出，不是改造标准。

• 除第一条外，检出特征 ≠ 必须消除。作者刻意的强调、文体要求的程式，都可以保留。
• 本表不规定怎么改——处理方式由你判断；本表只负责让你看见。
• 唯一的判据是：读者能不能从这个特征认出「这是机器写的」。

一、判断、转折与比较（默认禁止）

这三项是 AI 中文最硬的指纹，也是本表唯一带硬性限额的一组。不要等它们组成完整句式才认——单个功能字用得太密，本身就是滥用。

三者的判据是同一条，没有例外：

硬限额：每段至多 1 处。而且 1 处都嫌多——目标是接近零。

唯一允许超出限额的情形：删掉它，全文会崩（论点塌了、结论没了、读者接不上）。

单点检验：「把这一处删掉，全文是否崩溃？」不崩 → 删。

判断的滥用

• 怎么认：是 是它的标记——「这是…」「…是关键 / 前提 / 基础」「X 决定了 Y」「…是…的」。作系动词的纯叙述不算，算的是下断言。
• 为什么：「判断句的力量来自稀缺」——它是全文最重的那几句。满篇判断，等于满篇都在喊结论，等于没有结论。

转折的滥用（三者中最硬的一条）

• 怎么认：然而 / 但是 / 不过 / 却 / 反而 / 事实上。单个字用得太密即算，不必组成完整句式。
• 为什么：转折是承重结构——真正需要转的地方极少。用得密，是拿它制造"论述感"：看起来在推进，其实只是在绕。

比较的滥用

• 怎么认：比 / 更 / 最 / 而 / 则 / 相比 / 对比之下。注意区分真比较与构词——「对比之下」是标记，「比如」「加勒比」不是。
• 另有结构层：连续 ≥3 个小节拿同一个对象作对照。这一条同样要过上面的检验——整节的对照必须是论证本身，不是装饰；做不到就不许有。
• 为什么：比较是论证手段，不是论证本身。每一节都要靠对照撑着，说明每一节都没有自己的推进。

二、句式

句式重复

• 认法：同一句式结构在篇内反复出现。
• 豁免：作者刻意设计的上下呼应、排比——那是有意为之，不是病。

句式单一

• 认法：全篇句型集中，缺短句、独句、问句、插入语、停顿。

三、词汇

实词复用

• 认法：同一实词（如「条件」「结构」「体系」）跨段反复出现。

空话

• 认法：把这句话删掉，读者损失了什么信息？ 答得出 → 留着；答不出 → 是空话。
• 不给词表：列出禁用词只会让措辞换一层皮——空话不会变少，反而多一层伪装。判断只靠上面那一问。

四、结构

节间同构

• 认法：逐节写出骨架（如「论点→证据→对照→小结」），出现 ≥3 节同名骨架。
• 为什么露馅：作者的声音体现在结构选择上。每一节一个模子，那是模板不是写作。

段长分布集中

• 认法：长短段失衡，全篇段长落在相近区间。

五、证据

无据断言

• 认法：断言追不到证据。
• 处理：回去找证据——不是停笔，也不是标个记号了事。
• 证据诚实：区分「已核实 / 有来源」与「推测 / 未核实」；不夸大，不在没有证据时声称"验证通过"。引用要给得出出处，来源与版本可核查。

修正记录

修正记录（2026-09-17）：本节整体重写。原「中文十二检」的十二条规范全部废弃（密度检、主语检、翻译腔检、具体检、主题句检、推进检、节奏检、骨架检、结论检、首尾检、标题检、篇幅检）。

废弃理由：原版把通用写作规范当成了 AI 特征——那些条目跟 AI 味无关，任何写作课都会讲，占满篇幅却抓不住真问题；而真正该抓的三处方向全偏（翻译腔去抓代词与被动，真凶是过量的判断与转折；节奏检去数句长，真凶是句式与设计上的重复；骨架检让人停笔，正解是回去找证据）。更根本的是，十二条硬阈值构成一个固定目标形态，把不同文本推向同一副面孔，本身就在制造新的 AI 味。

本版原则：只检出、不规定改法；不给词表；一切判断以「先决：文体与用途」为前提。

修正记录（2026-09-17）：「判断、转折与比较」独立成组，并定为硬性限额。两轮修正叠加：① 原来只认完整句式，漏掉了真正的战场——是 / 然而·但·却·反而 / 比·更·最·而·则 这类功能字用得太密本身就是特征，故每项都分层到功能词层；② 原来的"数密度"标准仍然过松（三成的判断句都算通过），改为默认禁止 + 唯一例外——每段至多 1 处、且 1 处都嫌多，只有"删掉全文会崩"才允许超出。这是本表唯一带硬性限额的一组，其余特征仍是纯检出。

完成标志

• [ ] 三件事（读者 / 得到什么 / 文体）都有明确答案
• [ ] 骨架已产出：主张 ≤30 字，每条支撑都带证据
• [ ] 素材不足处已标 [需补事实]，未编造任何数字 / 引语 / 案例 / 来源
• [ ] AI 特征表逐项过完，每个特征都写了「在哪一处、你怎么判断的」（未命中写「无」）
• [ ] 已落盘（或用户明确要求仅对话输出）
• [ ] 对话回复仅含路径 + 主张一句话 + 待补事实清单
• [ ] 若分派了多份交付物：每份有单一 owner 端到端负责，无阶段接力，无全批等待

反绕过红线

• 素材不足仍然开写，靠生成的句子把篇幅凑满 → 底线违规。
• 支撑句没证据却写进了骨架 → 底线违规（后续必然靠编造补齐）。
• 自检只写「已检查」不写具体位置与改动 → 等于没自检。
• 用"行业习惯说法"为一句空话开脱 → 答不出「删掉它读者损失了什么」，那就是空话。
• 用「大约」「若干」「相关数据表明」掩盖拿不到的数字 → 属于编造的变体。
• 把没核实的东西写成「已验证 / 有据可查」 → 违反证据诚实；只能标推测或标 [需补事实]。
• 自检只写了词汇层（最好判断的那几项），回避了句式与结构 → 特征表必须逐项过，缺项即未完成。
• 判定为项目文件夹却自行把文稿写进 docs/ → 路径必须由用户指定。
• 把同一篇稿子拆成"调研的人 / 搭骨架的人 / 写的人 / 审查的人"接力，或等一整批全部完成才往下走 → 违反横向交付合约与滚动补位。