Archived
xcsandClaude Opus 5
0aa2fc11b0
**资料文件全链**(用户:审核资料这一步要真产出 word/excel/md/html,前端能渲、点资料名能开)
接手时这一步一个文件都产不出来 —— S3 剧本白纸黑字写着「file_ref 本 MVP 阶段可留空」。
文件是台账那一行的投影,不另存一份:
· 声明 `file:{titleColumn,bodyColumn,formatColumn}`,它同时是授权面(没声明就点不开)
· 现造真字节 —— docx/xlsx 是自己打的 OOXML 包(zip-write:store+CRC32,零依赖)
· 读回来渲 —— 解的就是造出来那份字节,渲得出来才证明文件是真的
· 件上 `data-file-of` → 工作区二级界面(Word 纸面/Excel 网格/渲好的 md/沙箱 html)+ 下载原件
放行落地前把每一份冻进 `sys.task_asset_file`(迁移 0029):归档件点开的必须是签字那一刻
那一份,而资料落在主数据上、试跑单不落正式表 —— 不存这一份,收工后一个都点不开。
工作成果里「产出的资料」自成一摞。Markdown 富文本渲染顺带销账(仍零依赖)。
**Harness**
· 画面按「这一拍办完之后」在办的那一步挑 —— 从前拿拍首的局面决定拍尾的事:
收掉 S4、发出 S5 的卡,而屏上还摆着 S4 的只读件,人无处可填(墙要配路第四次现形)
· 验收「重做」真能退回重做,且打回后台账没动就不许再提交(软硬两段,不锁死单子)
· 立监听的授权面是清单声明;发卡的授权面是调人预算,不是计划项
· 读工具同参重调有兜底;空转写身后还有行动就不废串;finish 的 doneWhen 按写完后的草稿算
**界面**
· 翻件与翻页各归各位(从前二选一,多卡多页时页翻不动);没得翻写「—」不写 0/0
· 工作成果详情能翻份;表宽超出能横滑(E04/I01 抄版式时把 overflow-x 抄丢了)
· 查看面灰底滚过一屏变白 —— 两条独立的路都治了(沙箱内不同色 / 弹性子项不长个)
· 测试台「取不到」不再当成「还活着」
**活动**
E04 关系覆盖、I01 品牌内容各自补到验收线:判据全读基座数、判据指向的东西摆上卡面、
样例满载且名字 ≤14 字;提交前要裁的判据搬进说明书(模型会压拍,压过之后只有说明书还在)。
验收:e2e i01 4/4、e04 3/3 全部 released,资料在办中渲得出、放行后存了档点得开;
门禁 typecheck/lint/depcruise/1628 测全绿。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EEJX8Z7CHejvwmDQyPQuBX
465 lines
32 KiB
TypeScript
465 lines
32 KiB
TypeScript
/**
|
|
* I01 品牌形象与销售工具包管理的案例模型 —— **双表示同版本**:CMMN XML(机器面)与
|
|
* 案例说明书(叙事面)。方法论与文件结构照抄 E04(`crm-relationship-coverage`)已验证过的样子。
|
|
*
|
|
* 业务出处:`docs/SS01-客户与市场/i01-html/I01-活动流程与工单说明.md`(7 步业务链条,
|
|
* 工单只针对生产流程①→⑤,复盘⑥⑦独立拎出不并入)与
|
|
* `docs/SS01-客户与市场/Demo-E04-I01-Activity台账关联与设计.html`(L-01/L-05 台账字段表)。
|
|
*
|
|
* 7 个业务步收成 6 个案例模型项,非逐一对应:
|
|
* ① 需求识别与受理 → S1_identify_requirement(AI 起草)+ S2_requirement_confirm(人核对);
|
|
* ②③ 市场依据采集 + 内容创作 → S3_gather_and_draft(一项,AI,纯加工态);
|
|
* ④ 内部审核与调性把关 → S4_draft_review(决策卡循环,通过/驳回+AI重做);
|
|
* ⑤ 发布入库 → S5_publish_prep(AI 拟发布)+ T_release(终局验收放行)。
|
|
* ⑥⑦ 分发追踪与复盘迭代**不在这份案例模型里**(业务说明明文:工单只针对生产流程,
|
|
* 复盘是独立触发的另一条时间轴,不并入这一次生产任务)。
|
|
*
|
|
* 与 E04 的一处刻意不同:I01 没有「AI 做不到、必须人去线下执行」的环节
|
|
* (内容初稿由 AI 草拟,人只审不做)——所以只有 1 张执行工单(S2),
|
|
* 少 E04 那张「执行经营动作」;验收工单反倒多一张(S4 审初稿 + T_release 发布确认),
|
|
* 与 E04(S4 审计划 + T_release 台账更新)结构同型。
|
|
*/
|
|
|
|
export const CMMN_XML = `<?xml version="1.0" encoding="UTF-8"?>
|
|
<definitions xmlns="http://www.omg.org/spec/CMMN/20151109/MODEL">
|
|
<case id="brand-content-toolkit">
|
|
<!--
|
|
案卷项的 id 就是任务视图里的键名。入参顶层是 trigger/reason/requester/targetCustomer/note
|
|
五个字段(不进这份 caseFileModel——没有谓词引用它们,S1 的步骤 reads 里单独声明);
|
|
content_brand_* 与 content_asset_* 那几个是基座读数(行数 / 缺必填 / 按值计数,
|
|
由基座现算,模型碰不着)。
|
|
-->
|
|
<caseFileModel>
|
|
<caseFileItem id="content_brand_requirement_rows" name="内容需求行数(基座现数)"/>
|
|
<caseFileItem id="requirement_confirmed_total" name="内容需求已核对确认(人环走完的凭据)"/>
|
|
<caseFileItem id="content_asset_rows" name="内容资产行数(基座现数)"/>
|
|
<caseFileItem id="content_asset_missing" name="内容资产缺必填的行数(基座现数)"/>
|
|
<caseFileItem id="draft_approved_total" name="内容初稿已审核通过(仅通过时置一)"/>
|
|
<caseFileItem id="content_asset_content_status_published" name="已置为已发布状态的行数(基座现数)"/>
|
|
<caseFileItem id="publish_prepared_total" name="发布准备已收口(S5 写完时置一)"/>
|
|
</caseFileModel>
|
|
<casePlanModel id="plan" name="品牌形象与销售工具包管理" autoComplete="true">
|
|
<!-- ① 内容需求已起草 —— 人核对那一步的入场前提 -->
|
|
<sentry id="s_requirement_drafted">
|
|
<onPart id="op_rd" caseFileItemRef="content_brand_requirement_rows"><standardEvent>update</standardEvent></onPart>
|
|
<ifPart id="if_rd"><condition>content_brand_requirement_rows > 0</condition></ifPart>
|
|
</sentry>
|
|
<!-- ① 内容需求已核对 —— 采集与创作那一步的入场前提 -->
|
|
<sentry id="s_requirement_confirmed">
|
|
<onPart id="op_rc" caseFileItemRef="requirement_confirmed_total"><standardEvent>update</standardEvent></onPart>
|
|
<ifPart id="if_rc"><condition>requirement_confirmed_total > 0</condition></ifPart>
|
|
</sentry>
|
|
<!-- ②③ 内容初稿已草拟且齐 —— 审核那一步的入场前提 -->
|
|
<sentry id="s_draft_ready">
|
|
<onPart id="op_dr" caseFileItemRef="content_asset_rows"><standardEvent>update</standardEvent></onPart>
|
|
<ifPart id="if_dr"><condition>content_asset_rows > 0 and content_asset_missing = 0</condition></ifPart>
|
|
</sentry>
|
|
<!-- ④ 内容初稿已审核通过 —— 拟发布那一步的入场前提 -->
|
|
<sentry id="s_draft_approved">
|
|
<onPart id="op_da" caseFileItemRef="draft_approved_total"><standardEvent>update</standardEvent></onPart>
|
|
<ifPart id="if_da"><condition>draft_approved_total > 0</condition></ifPart>
|
|
</sentry>
|
|
<!--
|
|
⑤ 发布已准备好 —— 放行门的入场前提。
|
|
认「办完了没有」:发布状态已置且不缺必填、且 S5 自己显式记了账
|
|
(publish_prepared_total 是写完之后才产生的数,不是「写过一笔就算数」)。
|
|
-->
|
|
<sentry id="s_publish_ready">
|
|
<onPart id="op_pr" caseFileItemRef="publish_prepared_total"><standardEvent>update</standardEvent></onPart>
|
|
<ifPart id="if_pr"><condition>publish_prepared_total > 0 and content_asset_content_status_published > 0 and content_asset_missing = 0</condition></ifPart>
|
|
</sentry>
|
|
|
|
<!-- ① 识别内容需求,铸造 round_ref(能算的不问人) -->
|
|
<humanTask id="S1_identify_requirement" name="识别本轮内容需求"/>
|
|
|
|
<!-- ① 交人核对需求清单(增删改)—— 触达世界前的人环,不给 doneWhen -->
|
|
<humanTask id="S2_requirement_confirm" name="需求受理:核对需求清单,增删改">
|
|
<entryCriterion id="ec_s2" sentryRef="s_requirement_drafted"/>
|
|
<itemControl><manualActivationRule id="m_s2"/></itemControl>
|
|
</humanTask>
|
|
|
|
<!-- ②③ 采集市场依据 → 草拟多语言内容初稿(一项,不触达世界) -->
|
|
<humanTask id="S3_gather_and_draft" name="采集市场依据、按 BT 层级草拟内容初稿">
|
|
<entryCriterion id="ec_s3" sentryRef="s_requirement_confirmed"/>
|
|
</humanTask>
|
|
|
|
<!-- ④ 内容初稿审核 —— 决策卡循环,通过或驳回+AI重做,不给 doneWhen -->
|
|
<humanTask id="S4_draft_review" name="内容初稿审核:通过或驳回(驳回则AI修订重提交)">
|
|
<entryCriterion id="ec_s4" sentryRef="s_draft_ready"/>
|
|
<itemControl><manualActivationRule id="m_s4"/></itemControl>
|
|
</humanTask>
|
|
|
|
<!-- ⑤(前半)拟发布:版本号递增、状态流转、登记场景与 BT 标签(不触达世界,给 doneWhen) -->
|
|
<humanTask id="S5_publish_prep" name="拟发布:版本递增、状态流转、登记场景与标签">
|
|
<entryCriterion id="ec_s5" sentryRef="s_draft_approved"/>
|
|
</humanTask>
|
|
|
|
<!-- ⑤(后半)发布确认:终局唯放行,必须人工激活 -->
|
|
<humanTask id="T_release" name="发布确认放行">
|
|
<entryCriterion id="ec_rel" sentryRef="s_publish_ready"/>
|
|
<itemControl><manualActivationRule id="m_rl"/></itemControl>
|
|
</humanTask>
|
|
</casePlanModel>
|
|
</case>
|
|
</definitions>`;
|
|
|
|
/**
|
|
* 案例说明书 —— **只写整单一以贯之的事**(逐步做法归剧本,两处不重复写同一件事)。
|
|
*/
|
|
export const NARRATIVE = `§0 开案:**这一轮要生产哪份对外内容资产,产完把它审核发布**。
|
|
入参五个顶层字段:
|
|
· \`trigger\`——**必有**,\`"proactive"\`(主动触发)或 \`"reactive"\`(被动触发·使用方请求),
|
|
翻成人读标签写进 \`content_brand.verdict.trigger\`(报告上不摆系统内英文码)。
|
|
· \`reason\`——仅 \`trigger:"proactive"\` 时可能有,四种之一:\`"strategy_shift"\`(战略调整)/
|
|
\`"new_market"\`(进入新市场)/ \`"tool_outdated"\`(工具过期)/ \`"monthly_update"\`
|
|
(月度定期内容更新)。
|
|
· \`requester\`——仅 \`trigger:"reactive"\` 时可能有,四种之一:\`"E04"\`(关系覆盖需要价值
|
|
传递素材)/ \`"T03"\`(触达需要材料)/ \`"T04"\`(攻坚需要定制内容)/ \`"E03"\`(方案需要支撑)——
|
|
T03/E03 在本仓库尚未实现,只是描述来源,不必真去调它们。
|
|
\`reason\`/\`requester\` 二选一有值,翻成人读标签一起写进
|
|
\`content_brand.verdict.trigger_detail\`(对照表见下方 S1 的 guide)。
|
|
· \`targetCustomer\`——选填,定向客户的编码(如为特定客户定制素材);通用内容留空。
|
|
· \`note\`——本轮背景说明(选填),帮你判断内容侧重与紧迫程度。
|
|
|
|
**成品是三样东西,缺一不可**:①一份**核对过的内容需求清单**;②一份**经审核通过的
|
|
内容初稿**(多语言,按 BT 层级定制结构);③**写入 L-05 品牌内容库的正式发布记录**
|
|
(版本号、状态流转、场景与 BT 标签登记齐全)。
|
|
|
|
**AI 承担信息汇总、记录与初稿生成,人负责判断与决策**:识别需求、采集市场依据、
|
|
草拟初稿、拟发布,都是你的活;核对需求清单、审核初稿、签字发布,三道都要人过。
|
|
|
|
**没有物理执行环节**:与 E04 不同,I01 没有「AI 做不到、必须人去线下办」的步骤——
|
|
内容初稿由你草拟,人只审核通过或驳回,不亲自动笔、不用到场。
|
|
|
|
**五步走**:识别需求 → 人核对 → 采集依据+草拟初稿(一步) → 人审核(可能来回改一轮)→
|
|
拟发布 → 人签字放行。
|
|
|
|
【这一单唯一的岔路口 —— 内容初稿审核,长这样,无论哪一拍都照这个发,别自己另编一张】
|
|
审核不是一次性的:人可能驳回、要求你按他的意见改。**这一步只在 S4_draft_review
|
|
这一项里发生**,发决策卡之前先在轨迹里找有没有已经答过、还没处理的 \`[card-reply]\`:
|
|
· **\`value\` 是 \`"approve"\`**——写 \`draft_approved_total=1\`,把这一轮草拟的每一行
|
|
\`content.asset\` 的 \`content_status\` 改成 \`reviewed\`(同 PK 覆盖写),finish 这一项,
|
|
别再发卡;
|
|
· **\`value\` 是 \`"reject"\` 或以 \`"custom:"\` 开头**——都算驳回:\`"reject"\` 是点了固定
|
|
按钮、没写具体意见,**不许再发卡追问理由**(那两个按钮点出来的回复永远没有 note,
|
|
再问一遍是把人指向一扇打不开的门);以 \`"custom:"\` 开头的,\`note\` 就是他写的具体
|
|
意见,按这条意见改。两种都要对 \`content.asset\` 做出至少一处实质性修订(同 PK
|
|
覆盖写,不开新计划项、不重新进入 sentry),然后**换一种问法**再发一张 decide 卡
|
|
(措辞不换会被系统当成同一张卡静默吞掉);
|
|
· **没有**——才发第一张 decide 卡。
|
|
{"kind":"decide","itemId":"S4_draft_review","allowCustom":true,
|
|
"ask":"内容初稿已草拟,共 <N> 份,请审核。",
|
|
"options":[{"value":"approve","label":"通过","recommended":true},
|
|
{"value":"reject","label":"驳回(不写具体意见)"}]}
|
|
三个 \`value\` 只有这三种形态:\`"approve"\`、\`"reject"\`、\`"custom:"\` 开头(人自己写的话)——
|
|
**别自己造第四种**。
|
|
|
|
【提交放行之前,先把三条裁量判据裁掉 —— 同一串 judge×3 + submit】
|
|
这三条机器判不了,**没裁过就提交必被拒**(拒回会点名是哪三条):
|
|
· "版本号与状态是否正确:版本号已更新、状态流转无误"
|
|
· "场景与 BT 标签是否登记完整"
|
|
· "多语言版本是否齐全"
|
|
criterion 照上面整句原样抄;裁成 satisfied=false 照样提交得了 —— 理由连着卡交给签字的人。
|
|
**这条写在这儿而不是只写在 T_release 的剧本里**:拟发布与提交常被压成同一拍,
|
|
那一拍摊开的是拟发布那一步的做法,T_release 的剧本这时看不见 —— 说明书每拍都在。
|
|
|
|
【一路上要说话】负责人正看着这一单。**每一拍带一句 say** —— 说业务的话:
|
|
识别到几条需求、初稿写了几份、发布准备好了什么;不说系统词。
|
|
到了要找人的那一拍,先说清这一轮办完了什么、为什么现在需要他。
|
|
|
|
【怎么把一项干完 · 一拍连做】write 和 tool 都不会自动收步 —— 做完用 finish 宣告。
|
|
动作排进同一拍的 actions 串一口气给;只有发卡 / 提交(挂起)必须停拍。
|
|
**这一单常路 7-9 拍就该收口**(比常路多两道人环:需求核对 + 初稿审核 + 放行,共三次;
|
|
审核若被驳回会多出一到两拍)。
|
|
|
|
§Z 结案:AM Lead 在验收单上签字,系统把草稿合并进 L-05 正式版 ——
|
|
这一轮生产的内容资产正式上线,可供 E04/T03/T04/E03 调用(分发追踪与复盘迭代是
|
|
独立触发的另一条时间轴,不在这一单里)。`;
|
|
|
|
/**
|
|
* 步骤剧本 —— 一个计划项一条;`doneWhen` 是「成果已存在」的判据,不是「该不该做」。
|
|
*
|
|
* 三处不给 `doneWhen`:`S2_requirement_confirm`(交人核对触达世界)、`S4_draft_review`
|
|
* (要人拍板,且这一项内部可能循环)、`T_release`(签下去触达世界)——
|
|
* 给了等于给引擎一把替人签字的钥匙。
|
|
*/
|
|
export const CONTENT_STEPS = [
|
|
{
|
|
item: 'S1_identify_requirement',
|
|
intent: '识别本轮内容需求来源与类型,铸造本轮案号',
|
|
writes: ['content_brand.requirement', 'content_brand.verdict'],
|
|
/* 入参顶层字段不声明就会被整表段截断刀砍掉 —— 被动触发那几条路全靠这五个字段 */
|
|
reads: ['trigger', 'reason', 'requester', 'targetCustomer', 'note', 'content.asset'],
|
|
view: 'requirement-list',
|
|
tools: [],
|
|
doneWhen: 'content_brand_requirement_rows > 0',
|
|
guide: `第一件事:把这一轮**内容需求**列出来。
|
|
|
|
【先铸造本轮案号 round_ref】格式固定:\`'CTB-' + case:openedAt 按 YYYYMMDDHHmmss 格式化\`
|
|
(引擎注入的开案时刻,你不必也不许自己编)。**整单只有一个 round_ref**,写
|
|
\`content_brand.requirement\` / \`.verdict\` 时都用这同一个串 —— 造出两个号就是把一单裂成两单。
|
|
|
|
【识别需求】读 \`content.asset\`(已有资产,判断是否已有类似内容、避免重复):
|
|
· \`trigger:"proactive"\`——按 \`reason\` 映射:\`strategy_shift\`(战略调整)/
|
|
\`new_market\`(进入新市场)通常对应"公司介绍"/"能力声明"这类通用内容;
|
|
\`tool_outdated\`(工具过期)对应更新既有工具包;\`monthly_update\`(月度定期更新)
|
|
对应例行内容刷新,可参考已有资产里哪些版本号最旧、最久未更新。
|
|
· \`trigger:"reactive"\`——按 \`requester\` 映射到内容类型:\`E04\` 请求价值传递素材
|
|
→系统方案白皮书/案例集;\`T03\` 触达需要材料→销售工具包/选型指南;\`T04\` 攻坚需要
|
|
定制内容→系统方案白皮书(定向 \`targetCustomer\`);\`E03\` 方案需要支撑→技术规格书/
|
|
替代对照表。\`targetCustomer\` 有值就把这条需求的 \`target_customer\` 填成它。
|
|
|
|
一轮可以识别出不止一条需求(如月度更新可能同时刷新两三份内容)。
|
|
|
|
【写 \`content_brand.requirement\`,一条需求一行】(rows 收数组)
|
|
round_ref、req_seq(**必填**,本轮内从 1 递增)、content_type(**必填**,如
|
|
"系统方案白皮书"/"公司介绍"/"能力声明"/"销售工具包"/"案例集"/"品牌调性标准"/
|
|
"方案模板")、source(选填,一句需求来源,如"使用方请求(E04 价值传递)"或
|
|
"战略调整(进入俄罗斯市场)")、target_customer(选填,定向客户;通用内容写"—(通用)")、
|
|
scene(选填,**写人读标签**"首触"/"方案"/"攻坚"/"展会"/"报价"之一,按用途判断——这一列
|
|
在编辑面上是普通格子、不是徽标,不带翻译层,写 ASCII 码人看到的就是 ASCII 码)、
|
|
priority(选填,ASCII \`high\`/\`medium\`/\`low\`,按紧迫程度判断)、origin(固定写 \`ai\`)。
|
|
|
|
【同一拍写 \`content_brand.verdict\`(一行)】round_ref、trigger(**翻成人读标签写,
|
|
不写入参那个英文码**——\`"proactive"\`→"主动触发"、\`"reactive"\`→"被动触发")、
|
|
trigger_detail(把 \`reason\` 或 \`requester\` 也翻成人读标签写进来——
|
|
\`strategy_shift\`→"战略调整"、\`new_market\`→"进入新市场"、\`tool_outdated\`→"工具过期"、
|
|
\`monthly_update\`→"月度定期内容更新"、\`E04\`→"E04 关系覆盖需要价值传递素材"、
|
|
\`T03\`→"T03 触达需要材料"、\`T04\`→"T04 攻坚需要定制内容"、\`E03\`→"E03 方案需要支撑")、
|
|
target_customer(入参原样抄,没有留空)、note(入参原样抄,没有留空)、summary 一句人话
|
|
(本轮识别到几条需求、依据是什么)。写完 finish 这一项。`,
|
|
},
|
|
{
|
|
item: 'S2_requirement_confirm',
|
|
intent: '交人核对需求清单:增删改,确认本轮真正要生产什么',
|
|
writes: ['content_brand.verdict'],
|
|
reads: ['content_brand.requirement'],
|
|
view: 'requirement-list',
|
|
tools: [],
|
|
/* 不给 doneWhen —— 交人核对触达世界(manualActivation),引擎不替人收 */
|
|
guide: `需求清单起草好了,**该内容运营核对了** —— 这是本活动第一张执行单,零输入。
|
|
工作区摆的是需求清单的报告(编辑闸开着就能增删改),他在那份件上核对:AI 规则之外的
|
|
目标客户、适用场景、优先级、定制需求(如使用方要一份方案,他线下知道要针对某客户
|
|
做定向版)。
|
|
|
|
这一步标了人工激活:发卡就算启动,不必单发 start;人交回后你自己 finish。
|
|
|
|
【照这个骨架发,别少字段】(卡面是纯文本,steps/standard 里别写星号记号,别绑 \`blocks\`
|
|
或 \`fields\` —— 整份清单在工作区那份件上,执行卡零输入)
|
|
{"kind":"human","itemId":"S2_requirement_confirm","workOrder":"execution","card":{
|
|
"title":"需求受理:本轮共 <N> 条内容需求",
|
|
"ask":"AI 已按规则识别出 <N> 条内容需求,请核对确认。",
|
|
"steps":["工作区的件上核对需求清单:内容类型是必填,缺一条这一单走不到内容创作那一步",
|
|
"加一行 = 补充新需求(AI 规则之外的目标客户/场景/优先级/定制)",
|
|
"删一行 = 排除(AI 识别但实际不需要生产的需求)",
|
|
"改单元格 = 修正 AI 识别的内容 —— 尤其是目标客户、适用场景、优先级",
|
|
"改完保存,回这张卡提交"],
|
|
"standard":"需求清单里每一行内容类型都齐;该补充的都补充、该排除的都排除了。",
|
|
"basis":[{"k":"触发口径","v":"<照 content_brand.verdict 刚写的 trigger/trigger_detail 说,
|
|
如「主动触发:月度定期内容更新」或「被动触发:E04 关系覆盖需要价值传递素材」>"},
|
|
{"k":"AI 识别","v":"<N> 条内容需求"}]}}
|
|
发完这一拍就结束了(发卡挂起)。
|
|
|
|
【人交回之后】这一步你只做两件事,然后 finish:
|
|
① 写 \`content_brand.verdict.requirement_confirmed_total = 1\`;他在件上撤掉了行或加了行
|
|
的话,下一步的市场依据采集与内容创作按当下 \`content_brand.requirement\` 的实际行数走,
|
|
不必你重写。
|
|
② finish 这一项。**别在这一拍采集市场依据或草拟初稿** —— 那是下一步的活,这里做了也白做。
|
|
|
|
【这张卡一单只发一次】人交回来之后不许再发同一张卡 —— 缺必填有提交闸兜着,
|
|
卡回来时内容类型一定是齐的(或那几行已被他撤掉)。`,
|
|
},
|
|
{
|
|
item: 'S3_gather_and_draft',
|
|
intent: '采集市场依据、按 BT 层级草拟多语言内容初稿',
|
|
writes: ['content.asset', 'content_brand.verdict'],
|
|
reads: ['content_brand.requirement', 'market.signal', 'content.asset'],
|
|
view: 'draft-review',
|
|
tools: [],
|
|
doneWhen: 'content_asset_rows > 0 and content_asset_missing = 0',
|
|
guide: `需求确认了,**现在读市场依据、草拟内容初稿** —— 一拍连做,这一步纯加工态,
|
|
不必找人。
|
|
|
|
【采集市场依据】读 \`market.signal\`(L-01 宏观市场台账):按需求里的 \`target_customer\`/
|
|
业务背景筛选相关的 \`market_region\`/\`industry\`/\`chip_category\` 信号,归纳产业趋势与
|
|
差异化定位。**读不到相关信号是正常结果**(不是每条内容需求都有现成的市场信号支持)——
|
|
读不到就如实基于已有资产与客户信息拟定,别在报告里编一条不存在的市场依据。
|
|
|
|
【按 BT 层级草拟内容初稿】逐条 \`content_brand.requirement\` 草拟一份初稿:
|
|
· BT-01(采购/供应链层)侧重:供货能力 / 资质文件 / 渠道政策;
|
|
· BT-02(技术层)侧重:技术规格书 / 替代对照表 / 认证报告;
|
|
· BT-03(高层)侧重:系统方案白皮书 / 参考设计 / 成功案例。
|
|
需求没指明 BT 层级的,按内容类型判断("系统方案白皮书"多半是 BT-03,"技术规格书"多半
|
|
是 BT-02)。**维护多语言版本**:中文必备,俄罗斯市场相关(俄语区客户/进入俄罗斯市场
|
|
的需求)加俄语,其余按需求背景判断要不要加英语。同一份内容的多语言版本写进**同一行**
|
|
的 \`language\` 列(用" · "连接,如"中文 · Русский"),不必为每种语言各开一行。
|
|
|
|
读 \`content.asset\` 里已有资产与品牌调性标准,保持措辞一致、避免重复生产同一份内容。
|
|
|
|
【写 \`content.asset\`,一份内容初稿一行】(rows 收数组)
|
|
content_id(**必填**,格式固定 \`'CT-' + 本年年份 + '-' + 本轮内四位序号\`,如
|
|
"CT-2026-0001"、"CT-2026-0002",本轮内递增、不与已有资产的编号相撞)、content_type
|
|
(**必填**,照抄需求的 content_type)、title(**必填**,具体标题,不写"内容初稿"这类
|
|
占位词)、language(**必填**,如"中文"或"中文 · Русский")、version(**必填**,本步一律
|
|
写 \`v0.1\`)、scene(选填,照抄需求的 scene 人读标签)、content_status(固定写 \`draft\`)、
|
|
brand_tone(选填,按品牌调性标准挑 1-2 个最贴合的,如"专业 · 可信赖")、bt_tag(选填,
|
|
**写人读值** "BT-01"/"BT-02"/"BT-03" 之一,按上面那三档判 —— 这一列在件上是普通格子、
|
|
不带翻译层,写 ASCII 码人看到的就是 ASCII 码;验收工单要人核「BT 标签登记完整」,
|
|
核的就是它)、target_customer(选填,照抄需求的 target_customer)、file_ref(选填,
|
|
留空即可)、reviewer(选填,本步留空,S4 审核通过后再填)。
|
|
|
|
【**正文与格式:这一步真正要产出的资料**】(\`body_md\` 与 \`file_format\`,两列都**必填**)
|
|
人在下一步要审的是**资料本身**,不是一行标题 —— 件上点资料名就打开这份文件,
|
|
所以正文得真写出来。
|
|
|
|
· \`body_md\` = 这份资料的**全文,Markdown 原文**。照 BT 层级该有的结构写实内容:
|
|
一级标题一句话说清这是什么,再按"##"分节。**每一节都要有实打实的内容** ——
|
|
一句"回头再补"或者把人指去别处的话,等于这一份资料没产出。认得的写法就这几样,够用:
|
|
"# 标题" / "## 小节" / 段落 / "- 要点" / "1. 步骤" / "| 列 | 列 |" 表格 / "---" 分隔线 /
|
|
"**重点**"。多语言版本写进同一份正文的不同小节
|
|
(如 "## Русская версия"),不为每种语言另开一行。
|
|
· \`file_format\` = 这份资料**该以哪种格式交出去**,四选一,按内容形态挑,别一律写 md:
|
|
- \`xlsx\`:主体是表 —— 替代对照表、参数对比表、价格/交期清单;
|
|
- \`docx\`:正式文档 —— 系统方案白皮书、技术规格书、认证报告、渠道政策;
|
|
- \`html\`:要在网页上直接看的 —— 落地页文案、案例展示页;
|
|
- \`md\`:短说明、要点清单、内部速记。
|
|
挑 \`xlsx\` 的那一份,正文里**必须真有一张 Markdown 表格**(否则导出来是一张只有
|
|
标题的空表)。同一轮里几份内容各按自己的形态挑,不必统一。
|
|
|
|
【同一拍写 \`content_brand.verdict\`】summary 补一句人话(本轮草拟了几份内容、依据是
|
|
什么市场信号或已有资产)。
|
|
|
|
写完这一拍就结束(不必你 finish)——\`content_asset_rows > 0 and content_asset_missing = 0\`
|
|
一旦为真,引擎自己收这一步。`,
|
|
},
|
|
{
|
|
item: 'S4_draft_review',
|
|
intent: '内容初稿审核:通过就往下走,驳回则按意见修订后换一种问法再提交',
|
|
writes: ['content.asset', 'content_brand.verdict'],
|
|
reads: ['content.asset'],
|
|
view: 'draft-review',
|
|
tools: [],
|
|
/* 决策卡循环 + 要人拍板 —— 不给 doneWhen,引擎不许替人收 */
|
|
guide: `**动手之前先在轨迹里找一行 \`[card-reply]\` 带这一项的答复:**
|
|
|
|
· **没找到** —— 这是第一次,跳到下面【发一张决策卡】那一段;
|
|
· **\`value\` 是 \`"approve"\`** —— 把这一轮 \`content.asset\` 里状态还是 \`draft\` 的每一行
|
|
改成 \`content_status = "reviewed"\`(同 PK 覆盖写,\`reviewer\` 补一句"AM Lead 审核通过"),
|
|
写 \`content_brand.verdict.draft_approved_total = 1\`,finish 这一项,**不许再发卡**;
|
|
· **\`value\` 是 \`"reject"\` 或以 \`"custom:"\` 开头** —— 都算驳回,跳到下面【驳回之后】
|
|
那一段,修订初稿再重新发卡。
|
|
|
|
【这一步办完了没有,看一个数】\`draft_approved_total\`:它写成 1 就是这一步办完了,
|
|
引擎不会再把这一项交给你(它归零 doneWhen 帮不上忙,只有你自己 finish)。
|
|
|
|
【发一张决策卡,照这个骨架】(选项少于两个基座拒发;\`allowCustom\` 别漏 —— 少了它,人只有
|
|
两个固定按钮可点,连意见都没地方写;\`ask\` 每一轮都要按下面的规则换措辞)
|
|
{"kind":"decide","itemId":"S4_draft_review",
|
|
"allowCustom":true,
|
|
"ask":"内容初稿已草拟,共 <N> 份,请审核。",
|
|
"options":[
|
|
{"value":"approve","label":"通过","recommended":true,"consequence":"内容进入发布准备阶段"},
|
|
{"value":"reject","label":"驳回(不写具体意见)","consequence":"AI按调性标准复核一遍初稿,重新提交审核"}],
|
|
"basis":[{"k":"本轮初稿","v":"<N> 份,覆盖 <涉及的内容类型>"},
|
|
{"k":"调性依据","v":"专业 / 可信赖 / 高效 / 本土化"},
|
|
{"k":"想说明理由","v":"不点上面两个按钮,直接在下方输入框写你的意见再提交"}]}
|
|
发完这一拍就结束了(发卡挂起)。
|
|
|
|
【驳回之后 —— 不管有没有具体意见,都只处理这一轮,不许再追问一遍】
|
|
① \`value\` 以 \`"custom:"\` 开头 —— \`note\` 就是他写的具体意见,**按这条意见**修订
|
|
\`content.asset\`(同 PK 覆盖写对应的行,不开新计划项、不重新进入 sentry)。
|
|
② \`value\` 是 \`"reject"\`(点了固定按钮,没写具体意见)—— **不许再发卡追问理由**
|
|
(那两个按钮点出来的回复永远没有 note,再问一遍是把人指向一扇打不开的门,
|
|
会被同一句话拒回,连问出真话的机会都没有)。改成你自己复核:对照调性标准
|
|
(专业/可信赖/高效/本土化)重新审视措辞,技术数据有没有可疑处;复核后**至少要有
|
|
一处实质性变化**(改措辞、补细节、调标签,不能原样重发)。
|
|
③ **重新发卡的 \`ask\` 必须换一种说法**,带上修订轮次与改了什么,例如
|
|
"已复核并修订(第2稿:调整了措辞、补充了认证细节)请再次审核"——
|
|
措辞不换,系统会把它当成同一张卡:前两次静默吞掉(人看不到新卡),第三次直接拒。
|
|
**每一轮的 \`ask\` 都要与上一轮明显不同**,不止改个数字。
|
|
④ 再走一遍【发一张决策卡】那一段(用新措辞,\`allowCustom\` 仍然要给),然后这一拍结束
|
|
(发卡挂起)。
|
|
|
|
**这一步只在这一项里循环,不许把驳回意见带去改别的项**(S1/S2/S3 写下的东西不动)。`,
|
|
},
|
|
{
|
|
item: 'S5_publish_prep',
|
|
intent: '拟发布:版本号递增、状态流转、登记场景与 BT 标签',
|
|
writes: ['content.asset', 'content_brand.verdict'],
|
|
reads: ['content.asset', 'content_brand.requirement'],
|
|
view: 'publish-confirm',
|
|
tools: [],
|
|
doneWhen: 'publish_prepared_total > 0 and content_asset_content_status_published > 0 and content_asset_missing = 0',
|
|
guide: `审核通过了,**现在拟发布** —— 一拍连做。
|
|
|
|
【写 \`content.asset\`,把审核通过的每一行(\`content_status = "reviewed"\`)改成拟发布态】
|
|
(同 PK 覆盖写)version(**必填**,由 \`v0.1\` 改成 \`v1.0\`;若这份内容是已发布内容的
|
|
修订版本(\`content.asset\` 里已有同标题的 \`published\` 行),小版本递增,如 \`v1.1\`)、
|
|
content_status(**必填**,固定写 \`published\`)、scene(**必填**,若上一步没填齐,这一步
|
|
补上 —— 发布前场景必须登记完整)、bt_tag(**必填**,同上,人读值 "BT-01"/"BT-02"/"BT-03";
|
|
场景与 BT 标签这两列**声明里钉的就是「发布态才必填」**,状态一写成 published,
|
|
它们空着就会被红带、提交闸、放行门 L2 同时拦下)、brand_tone(选填,若上一步没填,
|
|
这一步按调性标准补)。
|
|
**这一步只是把状态写进本单草稿层,不是真的对外发布** —— 铁律②:草稿层的变更要等
|
|
T_release 人签字放行才合并进 L-05 正式版、真正对外可见。
|
|
|
|
【同一拍写 \`content_brand.verdict\`】publish_prepared_total = 1、
|
|
content_produced_total = 这一轮拟发布的内容份数、summary 补一句人话(这一轮生产了
|
|
哪几类内容、准备发布几份)。
|
|
|
|
写完 finish 这一项 —— 或者不必你 finish,\`doneWhen\` 会在必填列都齐的那一刻自动收步。`,
|
|
},
|
|
{
|
|
item: 'T_release',
|
|
intent: '发布已准备好,提交放行交 AM Lead 验收;被打回就按意见改完再交',
|
|
/* 被打回重做时要改的就是这两张 —— 不声明就写不进去(写的授权面是台账声明) */
|
|
writes: ['content.asset', 'content_brand.verdict'],
|
|
reads: ['content.asset', 'content_brand.requirement'],
|
|
view: 'publish-confirm',
|
|
tools: [],
|
|
/* 放行触达世界,必须人按一下 —— 引擎不自动收它 */
|
|
guide: `拟发布内容齐了、必填也补齐了,**可以走放行了**
|
|
(T_release 人工激活:动它就算启动,不必单发 start)。
|
|
|
|
【**先看一眼轨迹里有没有「验收被打回重做」**】有的话,这一拍**不是**再提交一遍 ——
|
|
人已经看过这份成果并把它退回来了,原样递上去他看见的还是刚被他打回的那一份
|
|
(基座那道闸也会当场拒:「打回之后台账一个字没改」)。照他的意见改**台账本身**,
|
|
改完这一拍再 judge + submit:
|
|
· 他说**版本号/状态不对** → 改 \`content.asset\` 的 \`version\`/\`content_status\`(同 PK 覆盖写);
|
|
· 他说**场景或 BT 标签没登记全** → 补 \`scene\`/\`bt_tag\`;
|
|
· 他说**语言版本不齐** → 补 \`language\`(同一行用" · "连接,不新开行);
|
|
· 他说**标题/调性不合** → 改 \`title\`/\`brand_tone\`;
|
|
· 他**没写具体意见**(只点了重做)→ 自己把这几份内容复核一遍,挑最站不住的那处改实,
|
|
**至少改对一处**;实在判断不出他要什么,发一张零输入执行工单问清楚,别原样重提。
|
|
**改的是值,不是行**:同一行覆盖写,别新开行 —— 那会把收步判据与发布份数弄假。
|
|
|
|
【没被打回(或已按意见改过了)】先把裁量判据裁掉,然后 submit,同一拍连做:
|
|
|
|
· judge criterion="版本号与状态是否正确:版本号已更新、状态流转无误" —— 逐条看
|
|
\`content.asset\` 的 \`version\`/\`content_status\`:版本号已从 \`v0.1\` 更新、状态流转
|
|
(草稿 → 已审核 → 已发布)每一步都走过没有跳步,就 satisfied=true;有一条对不上,
|
|
satisfied=**false**,rationale 逐条写清,交签字的人定。
|
|
· judge criterion="场景与 BT 标签是否登记完整" —— 核对每条拟发布内容的 \`scene\`/
|
|
\`bt_tag\` 是否都有值(这两列在声明里是「发布态必填」,基座也数得出来;
|
|
你要判的是**登记得对不对**,不只是有没有值)。
|
|
· judge criterion="多语言版本是否齐全" —— 核对 \`language\` 是否覆盖了这条内容该有的
|
|
语言版本(如面向俄罗斯市场的内容至少要有俄语)。
|
|
**裁成不满足照样能提交** —— 理由连着卡一起交给签字的人。criterion 照判据名整句原样抄,
|
|
写别的名字对不上。
|
|
|
|
这一单没有分支去向 —— 全程线性,只发一口 \`content-published\`,不必你选出口。
|
|
|
|
终局唯放行:你不能自己宣布完成。`,
|
|
},
|
|
];
|
|
|
|
/**
|
|
* 阶段 —— 进度条的刻度,只给人看。除放行外每个计划项恰属一个阶段;
|
|
* 放行那一格由基座统一加,人看到的是 x/3。
|
|
*/
|
|
export const CONTENT_PHASES = [
|
|
{ name: '需求识别与受理', items: ['S1_identify_requirement', 'S2_requirement_confirm'] },
|
|
{ name: '采集与创作', items: ['S3_gather_and_draft'] },
|
|
{ name: '审核与发布', items: ['S4_draft_review', 'S5_publish_prep'] },
|
|
];
|