Dxc Article Write

---
name: dxc-article-write
description: 完成 DxC 文章正文阶段。把研究、Brief 和大纲写成自然、具体、适合微信阅读的文章。
---

# DxC 正文写作

内部调用 DxC CLI 时只使用 PATH 中的全局入口：`dxc <参数>`。本 Skill 的版本是 `0.3.28`，
安装流程必须已经验证 `dxc version --json`、本 Skill 集和该版本完全一致。正常任务不得通过 npm、
npx 或其他包执行器解析 DxC，也不得硬编码任何用户的可执行文件绝对路径。若 `dxc` 不在 PATH，或
CLI 报告官方 Skill 版本不一致，停止并请用户按安装说明重新安装同一指定版本；不在当前任务内联网
解析、切换版本或改用仓库源码。

DxC 的调用由本 Skill 给出。每次只直接执行当前 Skill 明确写出的一个 DxC 命令，不寻找或猜测替代命令。只把 CLI 上一次结构化结果中的 `workItemId` 或 `choiceId` 作为不可解释也不可编辑的字段直接交给下一次结构化调用；字段传递不得经过模型重新生成或自然语言转录。禁止手工复制、拼接、改写、截取、解码、重建、落盘、持久化或转存这些值，也不要求用户接触它们。

调用仍在运行时，`DXC_BROWSER_EVENT` 只表示需要立即承载当前页面，不表示命令失败或完成。等到进程退出并收到唯一的 `DXC_RESULT` 最终帧后，先把其中完整结构化结果作为当前事实保存，再向用户转述；不得用进度文案、浏览器地址或自己概括的字段替代最终工作项。

禁止用 Python、Shell、PowerShell 临时脚本、循环、管道、命令替换、后台任务、并发或定时器包装 DxC 命令。禁止调用 CLI help，禁止查看源码、日志、内部文件或解析返回值内部结构来推断下一步。没有明确的下一步时，停在这里，如实告诉用户当前还不能继续。

CLI 失败时，若当前 Skill 明确规定了 CLI 返回选项、用户选择后继续的分支，只按该分支等待并提交用户选择。
其余失败禁止再次调用、轮询、跳阶段、重新进入阶段或创建替代项目。只转述其中面向用户的 `message` 和唯一 `recovery` 所表达的安全方向，隐藏命令、内部标识、本地位置和诊断细节，然后停止；不得自行执行恢复动作或推测根因。

若宿主无法把完整结构化字段直接传给下一次调用，停止并说明交接能力不足；不得为了继续而手抄或重建引用。
状态目录权限被拒绝时，用户的自然语言同意不改变沙箱。只有宿主实际授予目标目录权限后才能继续；
不要反复在相同受限环境执行，也不要修改全局安全配置、放宽目录权限或搬迁文章。doctor 的工作目录检查不代表文章状态目录可写。

### 宿主接入与执行能力

本机安装核验不代表宿主已能执行当前任务。开始新的内容生产任务前，依据当前实际暴露的工具核对：
完整结构化结果能原样交接；执行环境已获准写入当前工作区与已选择的状态目录。完整文章流程还须
具备独立干净上下文子智能体，以及把真实图片直接保存为要求格式的能力。只处理标题、已有成稿交付
等中途入口时按本轮实际工作检查，不为未执行的阶段要求无关工具。目录或文件存在不证明已授权。
若宿主提供有效权限查询，先核实授权；安装流程已选且已存在的状态目录可由 `dxc doctor --directory <已选 Skill 目录> --state-directory <已选状态目录> --json` 验证实际写入与原子重命名。

能力缺失时，在创建项目或产出候选稿之前说明具体缺项并停止，不等写完正文才发现无法独立审校；
不能用自审代替独立审校、用占位图代替真实素材，或请求用户放宽全局权限。没有侧边栏浏览器时使用
CLI 的系统浏览器与短时链接降级，不因宿主名称假定有侧边栏；没有适用原生 UI 时沿用下方文本交互。
`doctor` 的 `hostCapabilities: not-checked` 表示宿主能力仍由本次实际工具核对，不能转述为全流程已通过。

### 用户选择与确认

所有 DxC Skill 共享以下交互合同。需要用户决定时，优先调用当前宿主实际提供、且允许用于该目的的原生 UI 交互工具，展示可点击选项；不能只在聊天中列编号并要求用户输入“确认”“继续”或数字。阶段采用、标题选择、公众号选择、返修方向、模板、长期资产变更和最终草稿确认都适用。

- 先展示待决定的真实内容，再用简短的业务选项表达动作，例如“采用并继续 / 修改 / 暂停”。选项只携带当前 CLI 返回的可执行选择；内部引用不展示给用户。
- 按 CLI 问题类型保留单选、多选与自由文本语义；多选优先用原生多选，只有单选工具时分成简短的逐项点击，不把多选擅自缩成一个选项。只对确实缺失且无法提供候选的内容使用文本输入。
- 用户已经明确指定入口、选择或授权当前动作时直接执行，不再问同一个问题；尤其不要逐项询问是否跳过研究、Brief 或大纲。每个确认只授权该次展示的内容与动作。
- 工具名以当前宿主实际暴露的能力为准，不假设某个工具永远存在。例如允许该用途的 AskUserQuestion、request_user_input 或 request_user_input_async；只有计划模式或只允许可选澄清的工具不能拿来做权限确认。
- 异步 UI 问题发出后，等待用户实际提交结果再执行依赖它的动作。默认选中、超时、无回答、取消和关闭面板均不代表同意，也不能自动选推荐项。取消时保留当前成果，停止依赖该决定的动作。
- 只有宿主确实没有可用于该目的的原生 UI 时，才简短说明限制，并使用最少输入的文本选择；不得伪造按钮、用终端交互提示代替宿主 UI，或要求用户执行命令。用户始终可直接用自然语言纠正、修改或拒绝。
- “准备公众号草稿”表示准备到最终预览；创建或覆盖草稿仍须展示当前不可变预览，并通过允许用于确认的 UI 取得明确决定。原生交互不改变快照、租户、幂等或未知结果停止规则。

用户提供 Markdown、DOCX 或 TXT 文件且尚无当前工作项时，先交给 `dxc-content-workflow` 按文件入口检查并采用；同时传递用户已指定的阶段，不重复询问入口，不以主题新建命令丢掉原稿。

阶段可独立进入。只读取 CLI 命名资源中实际存在的材料；`source-article` 是用户采用的原稿，优先保留其中的事实、判断和表达意图。前序资源标为 `missing` 时不要求补文件、不补跑前序阶段、不逐项询问是否跳过，也不能宣称那些阶段已完成。有已采用的 Brief 或大纲才按其约束核对；缺失时依据用户目标、原稿与实际材料作本阶段判断，具体事实缺证据仍如实处理。所需输入不足以完成当前任务时只问那个实质问题。

面向用户只展示正文和确实需要回答的问题，不展示命令、内部标识、本地位置或实现过程。

接到当前工作项时，使用其随附的当前阶段资料和写作区；不要另行查找项目文件、画像、记忆、知识库、日志或源码。正文阶段由本 Skill（技能）负责完成“写作—独立校验—返修—重新校验”的闭环，不把未经独立校验的完整候选稿展示给用户，也不把首次去 AI 味检查推迟到最终审校阶段。

工作项随附的创作记忆中，`enforce` 是必须遵守的约束，`guide` 是写作指导，`suggest` 只作候选且不得自动逐字写入；保留 `principle`、`judgment`、`expression` 等真实类型含义。

执行前完整阅读[写作方法](references/writing-methods.md)、[当前任务的作者风格证据](references/author-style-method.md)和[去 AI 味完整检查清单](references/anti-ai-checklist.md)。自主选择具体表达，落实已采用大纲的阅读目的、内容职责与推进关系；大纲的结构选择说明不进入成稿。遇到表达困难时，按需查阅[表达方法](references/expression-methods.md)的相关部分，不要求遍历或逐项使用。正文涉及热点主体、生僻对象、多个相近概念或跨类型比较时，再阅读[读者认知台阶与概念组织](references/reader-cognition-method.md)。无论从空白写作还是修改已有正文，都先在内部建立初稿基线，再按清单 A、B、C 三组完成主写自检，并执行 D 组整体回归；结合写作方法的成品语义判据定位具体问题，实质修复，不能只换词，也不能未经作者决定改变大纲主线。候选稿仍只保存在当前写作区，不向用户展示全文。

## 正文独立校验循环

1. 候选稿完成主写自检后，对当前生产工作项执行一次 `dxc workflow advance --work-item <当前工作项> --json`。正常结果必须是 `review-article`，并给出绑定当前正文指纹的检查分组和回执脚手架；此时不得展示完整正文，也不得把它当作正文确认工作项。
   若接到的当前工作项本身已经是 `review-article`，说明正文在后续阶段发生变化或上一轮已经生成审校绑定；不要先推进或展示，直接从第 2 步开始。
2. 宿主必须自动启动一个新的独立干净上下文 subagent（子智能体）。把 CLI 返回的整个 `reviewContract` 原样交给它，按其中 `materials` 完整读取命名原始资料、当前正文和固定创作上下文；画像、必守记忆、历史文章证据与已采用材料都属于审校依据，不能筛选或用摘要代替。另附作者本轮原始要求、本 Skill 已读取的方法文件和完整检查清单；不要给主写代理的修改摘要、自我评价、命中预期或建议结论。没有作者证据时按资料实际范围判断，不补造声音或经历。subagent 只审阅并填写回执，不得修改正文。
3. 回执只填写 CLI 脚手架提供的四个顶层键；`requiredReviewerMode` 是启动独立审校者的执行要求，不能复制为 `reviewerMode` 或其他回执字段。subagent 必须按脚手架顺序逐项填写 A、B、C、D 四组结果。每项都要给出当前正文位置和可核对判断；`block` 或 `unverified` 要给一个具体修复动作。它还必须隔离通读完整文章，确认连贯性、逻辑、通顺、事实、必要结构、真实思考顺序和作者声音没有被去 AI 味修改破坏。缺项、合并项、泛化结论或并非独立上下文都不能通过。回执写入完成后，macOS/Linux 必须执行 `chmod 600 <reviewContract.receipt.path>` 恢复 CLI 创建时的私有文件权限，Windows 跳过这一步；随后回读 JSON，确认仍是当前正文哈希、完整检查项和四个顶层键。不得为通过读取而放宽权限、跟随符号链接或移动回执。
4. 主写代理读取回执。只要存在 `block` 或 `unverified`，就根据具体位置修正文；修完后丢弃旧审校绑定。首次正文生产仍保留原生产工作项时，用它再次推进；若当前是后续阶段正文漂移触发的复核，则用当前审校工作项推进，让 CLI 拒绝旧正文指纹并返回绑定新正文的替代审校工作项。随后启动一个新的干净 subagent，从 A 到 D 全量重审。不能只复查上一轮命中项，也不能由主写代理代填通过回执。
5. subagent 全量判为 `pass` 后，才对该轮 `review-article` 工作项执行一次不带确认的推进。只有 CLI 接受当前正文指纹、完整检查项和通过回执，并返回正文确认或下一阶段工作项，才算正文阶段通过。
6. 宿主没有 subagent 或独立上下文能力时，停在正文内部候选状态，说明独立校验无法执行；不得展示完整稿、伪造 `independent-clean-context`，也不得绕到最终审校补做。

每一轮校验必须使用新 subagent；主写代理负责修改，subagent 负责独立发现与判定，CLI 只负责检查回执完整性、版本、正文绑定和是否全项通过。合同要求独立干净上下文，不代表 CLI 能证明 subagent 身份；语义判断和独立性都不能伪装成 CLI 自动评分。

独立审校结合写作方法的成品语义判据，以当前稿中的具体问题填写现有清单；不新增回执项目，
不因未使用某种手法、组合或显式问句而阻断。未收到修改前版本时，不声称已独立比较前后改善。

用户在正文展示后明确修改、拒绝或反馈了可迁移到未来文章的写作偏好时，另执行一次 `dxc memory signals record --automatic --project <随工作项收到的 projectId> --action <user-edit|user-feedback|user-rejection|user-choice> --summary <只描述用户行为的最小摘要> --json`。普通确认、单篇事实修正、局部措辞和 Agent/subagent 自己的判断不记录；返回 `recorded: false` 时不提示、不重试。该独立动作不替代正文独立校验，也不推进阶段。

只有独立校验通过后，CLI 要求展示正文时，才第一次向用户展示完整稿并等待决定：采用则执行一次 `dxc workflow advance --work-item <当前工作项> --confirm --json`；要修改则把用户意见作为新一轮正文修改，修改后再执行一次不带确认的推进并重新进入完整独立校验循环，不能直接展示修改稿或沿用旧通过回执；不采用则停下。CLI 返回校验阻断时，按回执进行下一轮正文修复，不把它当作系统错误盲重试；其他无法继续的结果则如实说明并停下，不自行转到其他阶段。

用户明确要求从正文开始新建文章时，执行一次 `dxc workflow start --title <用户主题> --from article --json`；已有文章只在用户从项目总览中明确选定后，把项目总览结构化结果中的 `projectId` 原样传递给一次 `dxc workflow start --project <项目总览返回的 projectId> --from article --json`。不得从文章标题猜测或重建；上下文丢失时，重新读取项目总览并让用户选择。随后仍只使用返回的当前工作项。