SI超级智能训练营 · 数据本体论主线

这是我的第一个动作：为我的企业从零开始初始化一个项目工程，后端接本平台给我开通的云服务资源，并把平台的核心技能与规则装进「当前项目 + 全局」两级目录，全程自动完成。如果提示词开头带了 sessionToken 就直接复用，不需要验证码；没有 token 时才需要你向我要手机号和验证码。

【第 1 步：最多问我 2 个业务问题就开工】
只问业务问题（这家企业做什么、我在这家企业里负责什么、想先解决什么），不要问技术问题，也不要让我选框架、选目录、选工具。把回答写成 docs/prd/requirements-interview.md。

【第 2 步：建项目骨架】
在项目根目录建立：app/（业务应用）；docs/prd、docs/design、docs/schema、docs/api、docs/test、docs/quality；storage/（资料区）。若是在已有项目上开工，保留它原有的框架与入口，不要为了套规范搬动 src/ 或 package.json。

【第 3 步：安装平台技能与规则，装到两级】
把平台核心技能与规则装到两个位置，两级都要装，缺一不可：
1. 当前项目目录（项目级，随项目一起入库、团队共享）；
2. 用户级全局目录（这台电脑上今后开任何新项目都自动生效）。
装完后分别列出两个位置各自的文件清单，向我确认两级都已就位。

【第 3.5 步：安装 Fmode 官方技能库（必装，缺了后面做不动）】
到技能中心安装 Fmode 官方技能库：https://skillhub.cn/skills/fmode/fmode-skills （包名 @fmode/fmode-skills）。
1. 先确认有没有 skillhub CLI：`skillhub --version`。没有就装：
   curl -fsSL https://skillhub.cn/install/install.sh | bash
   （装完若提示 command not found，把 $HOME/.local/bin 加进 PATH 再新开一个终端。）
2. 再装技能库；**必须用 --dir 指向本工具/分身的 skills 目录**，否则装了也不会被识别：
   skillhub install @fmode/fmode-skills --dir <你的 skills 目录>
   两级都要装：① 当前项目（项目级，随项目入库）② 用户级全局目录（今后任何项目都生效）。
3. 也可以直接把这句话交给 AI：「请根据 https://skillhub.cn/install/install.sh 的说明，把 @fmode/fmode-skills 安装到当前项目与全局的 skills 目录，装完回报版本与清单。」
4. 为什么必装：它一次装齐 Fmode 全部能力，其中**静态文件上传 / 发布**是关键——把图片、报告、HTML 等静态文件传到对象存储并拿到**公开可访问链接**（做看板、上传素材、发布页面都要用它）。没有它，「上传静态文件」这类需求会直接卡住。
5. 装完向我回报：包名与版本、装到了哪两级、各自文件清单；并**实测一次静态文件上传**——随便传一个文件，拿到公开链接后用浏览器打开确认能访问，把链接发我。这一条不通过就不算装好。

【第 4 步：应用后端接入平台给我开通的云服务资源】
- 本机云服务资源已经开通并落盘（~/.fmode/config/enterprise/current.json，含 appId / serverURL / functionsURL；masterKey 只在这份受保护配置里）。直接拿这一套填入使用，不要另起炉灶。
- 这份配置不存在或缺 appId 时：先向讲师或企业管理员要这一套企业云服务配置（appId / serverURL / functionsURL），拿到后再继续；**数字分身的初始化放到全部项目上线之后再做，这里不要做**；不要用我的账号去别的平台或别的云厂商「领取 / 开通 / 申请 / 切换」资源，更不要自建服务器处理普通 CRUD。
浏览器端普通数据读写直接用 Parse SDK（配置里的 appId + serverURL）；特权逻辑走配置里的 functionsURL：每个函数 handler(request, response)，自己鉴权、校验租户与入参、可重试处幂等、返回稳定错误形状。masterKey / databaseURI 只允许在服务端使用，绝不进浏览器包、仓库、日志。

【第 4.5 步：先读官方两个库，再动手】
前端统一使用下面这两个官方库（三个渠道都已发布，直接装即可）：
- **前端界面库**：npm `@fmode/skill-code-lit@1.0.0` ／ 源码 `github.com/fmodecn/skill-code-lit`
- **Agent 能力库**：npm `@fmode/skill-code-agent@0.1.1` ／ 源码 `github.com/fmodecn/fmode-code-agent`
先 `npm view <包名>` 或 `git clone` 下来读一遍 README 与目录约定，**再动手**；不要自创结构，也不要换成 React / Vue / Angular / 原生 HTML 等其它前端方案。
读完先用一句话向我复述你打算怎么按这套约定建工程，我确认后再进第 5 步。

【第 5 步：先契约后实现】
先写 docs/schema（表 / 字段 / 租户隔离）与 docs/api（云函数入参出参、错误形状），再写实现；业务表必须做租户校验。

【第 6 步：源码归档到 Git】
项目源码归档到 git.fmode.cn。没有账号时用平台云函数代理建号：POST https://server.fmode.cn/api/functions，body {token:<平台 sessionToken>, path:"/gogs/admin/proxy", params:{method:"POST", path:"/admin/users", body:{username:"fmode-<手机号>", send_notify:false}}}（服务端会强制该命名，返回的 token.sha1 即 API token）；再用它调 POST https://git.fmode.cn/api/v1/user/repos 建**私有**仓库（不要传 auto_init:true），push 时用 token 作密码（不要写进 remote URL）。不要 force-push、不要动别人的仓库、不要把凭据写进仓库。

【第 7 步：自检与汇报】
做一次构建 / 自检：产物里不得出现 token、masterKey、databaseURI、localhost 地址、源 .env 文件；并确认 Fmode 技能库（@fmode/fmode-skills）已在两级就位、静态文件上传实测能拿到公开链接。向我汇报：项目目录结构、用到的云服务资源、Git 仓库地址与 commit、技能装到了哪两级、下一步建议。

【铁律】
- 除验证码、手机号、姓名外，不让我做任何操作；目录选择、失败重试、环境判断全由你完成。
- 不伪造成功：任一步失败，如实汇报卡在哪、下一步怎么办。
- 不打印任何凭据、token、验证码、masterKey。
- 云服务资源只使用 ~/.fmode/config/enterprise/current.json 里的这一套，绝不自行去别的云领取 / 开通 / 申请 / 切换。

项目骨架已经建好。现在做一次「材料整理」，让这个工程成为以后长期干活的地方。全程自动完成，不要动业务代码逻辑。

【第 1 步：自查当前项目目录】
递归扫一遍当前项目目录，把里面的东西分成四类，逐类列出：
1. 代码与配置（源码、依赖清单、构建配置）——保持原位，不动；
2. 资料文件（文档、表格、图片、音视频、聊天导出、PDF、扫描件）——下一步要归档的；
3. 构建产物与缓存（dist/、node_modules/、.cache/、临时文件）——应进 .gitignore；
4. 不明文件（看不懂用途、可能是误放的）——单独列出，归档前先问我一句，不要擅自删。
告诉我每一类的数量与占用空间，哪些是重复的、哪些明显是旧版本。

【第 2 步：在项目根建资料区 ./storage】
在项目根建立 storage/ 目录，按资料性质分子目录（例如 storage/docs/ 文档、storage/sheets/ 表格、storage/media/ 图片音视频、storage/raw/ 原始导出与未知格式）。把上一步第 2、4 类资料移动进去，保持文件名可追溯（必要时重命名成「来源-内容-日期」的形式），并在 storage/README.md 里登记一张归档清单：原路径 → 新路径 → 一句话说明这是什么。

【第 3 步：定 .gitignore 规则（关键）】
在项目根的 .gitignore 里写清资料区的规则：
- **二进制文件不入库**：图片、音视频、PDF、Office 文档、压缩包、数据库文件、扫描件等一律忽略（例如 storage/media/、storage/raw/、*.pdf、*.docx、*.xlsx、*.jpg、*.mp4、*.zip）；
- **纯文本可入库**：Markdown（.md）与纯文本（.txt/.csv/.json/.yaml）可以提交，方便团队共享与 AI 读取——即 storage/docs/ 下的 .md、storage/sheets/ 下的 .csv 等保持可提交；
- 同时忽略依赖目录、构建产物、本地环境文件、凭据文件（.env、*credential*、*secret*、*token*）。
并在 storage/README.md 顶部用一句话说明这套规则：为什么二进制不入库（体积、隐私、Git 不是网盘）、为什么 md 与纯文本要入库（可 diff、可共享、可被 AI 直接读）。

【第 4 步：自检与汇报】
- 移动资料后重新跑一次构建 / 启动，确认项目仍然正常，没有因为搬动文件而断路；
- git status 确认：被忽略的二进制没有出现在待提交清单里，而 .md / 纯文本正常出现在待提交清单里；
- 向我汇报：自查结果（四类各自数量）、归档清单条数、.gitignore 里新增了哪几组规则、构建是否仍通过。
- commit 一次：「chore(storage): 资料归档到 ./storage 并定 .gitignore 规则」。

【铁律】
- 不删任何资料：拿不准的先进 storage/raw/ 并告诉我，绝不擅自删除或覆盖；
- 不动业务代码与依赖清单；
- 不把任何凭据、token、密钥移进 storage/ 或提交进仓库。

现在请你扮演一位资深的企业咨询顾问，来给我的企业做一次「业务诊断」。我没有准备任何材料，你也不要去任何代码仓库或 Git 里找底稿——全靠访谈。你的目标是问出一份《企业诊断底稿》，作为后续挖掘 AI 落地选题的原始依据。

【访谈对象与语气】
- 我是这家企业的老板/业务负责人，懂业务但不懂技术；你用大白话问，不要用咨询黑话。
- 每一轮最多问 3 个问题，问完就停下等我回答；我回答完你再决定下一轮问什么。
- 每次提问都带上你自己的猜测版答案（格式：❓问题 → ➡️我猜是……，理由一句话），我多数时候只要回「对/改成这样」，效率高很多。

【必须问到的四层（按顺序推进，问全了才往下）】
1. **部门与岗位**：这家企业有哪几个部门？每个部门里有哪些岗位？哪个岗位是「活儿最多、最重复」的？请把部门—岗位的对应关系列清楚。
2. **岗位核心工作流**：针对上面挑出的关键岗位，一个一个问清它的核心工作流——这件事什么时候被触发？中间分几步？每一步谁做、做什么、交什么？最后交付给谁？请把每一步都问成「动词 + 对象 + 交付物」的形式。
3. **结果目标**：每条工作流最终要达成什么结果？这个结果「做好了什么样、做砸了什么样」？谁来验收？有没有考核指标？
4. **依赖知识**：要干好这条工作流，需要哪些知识、资料、经验、案例、模板、话术、规则？（例如：产品参数、报价规则、历史案例、行业术语、客户档案、合规要求）。这些知识现在存在哪、谁能拿到？
最后收敛出一份「**重复且高频发生的具体事件**」清单：把上面四层里「反复在做、每次都要重来一遍」的具体事情单独摘出来，每条注明大概多久发生一次（每天/每周/每月）、每次大约花多久。至少要 5 条。

【访谈纪律】
- 我不要听行业通用套话，只要你的企业里真实发生的事；我讲得含糊时你继续追问，不要替我填一个「看起来合理」的答案。
- 一时问不出来的，记进「待补充清单」并在下一轮继续追，不要跳过。
- 全程不要问我技术问题（用什么工具、什么系统、什么框架），只问业务。

【收尾产出：《企业诊断底稿》】
访谈结束后，把结果整理成一份 markdown 底稿并写入当前项目的 storage/docs/ 目录，文件名 company-diagnosis.md，结构：
1. 企业一句话简介（做什么的、给谁做、规模）；
2. 部门—岗位清单与对应关系；
3. 关键岗位的核心工作流（一岗位一节：触发条件 → 步骤详解（每步谁做/做什么/交付什么）→ 交付给谁 → 结果目标与好坏标准 → 依赖的知识/资料）；
4. 重复高频事件清单（表格：事件名 / 所属岗位 / 频率 / 单次耗时 / 现在是人工还是系统）；
5. 待补充清单（还没问清的信息 + 下一轮要问什么）。
写完后向我汇报：底稿路径、覆盖了几个部门/岗位、摘出几条高频事件、还差什么没问清。

【铁律】
- 不编造：我只说了什么你就记什么，没说的标「待确认」，绝不替我把故事编圆。
- 底稿里不出现真实客户姓名、手机号等隐私，需要时只写「某客户」。
- 不要跳过访谈直接写底稿，也不要一次问完所有问题。

继续当我的企业咨询顾问。上一步的《企业诊断底稿》（storage/docs/company-diagnosis.md）已经写完，但我不确定它够不够。请你先自己体检，再不达标就继续追问我。

【第 1 步：底稿体检（逐项打分：达标 / 待补 / 缺失）】
拿下面这张及格线检查表逐条打分，每条给出「为什么是这个分」的一句话理由：
A. 部门与岗位：部门是否齐全？每个部门是否有 1 个以上具体岗位？是否点出了「活儿最多」的岗位？
B. 核心工作流：关键岗位是否都有完整工作流？每条是否都写清「触发条件 → 分几步 → 每步谁做/做什么/交付什么 → 交付给谁」？
C. 结果目标：每条工作流是否都有「做好了什么样 / 做砸了什么样 / 谁验收」？有没有可量化的指标？
D. 依赖知识：是否列出了支撑这条工作流所需的知识、资料、模板、规则？是否说明这些知识现在存在哪、谁拿得到？
E. 重复高频事件：是否至少有 5 条？每条是否有频率（每天/每周/每月）与单次耗时？是否注明了现在是人工还是系统？
F. 可推理度：仅凭这份底稿，你能不能在不猜的前提下写出 8 条像样的 AI 落地选题？如果有任何一条选题你必须靠猜，指出来是哪条、缺什么。
把体检结果写成一张表，列出所有「待补」和「缺失」项。

【第 2 步：继续访谈（追问到达标）】
针对每一条待补/缺失项，继续按咨询师的方式追问我：每一轮最多问 3 个问题，每个问题带你的猜测版答案。
- 我回答得上：记录进底稿，把该项改成「达标」。
- 我回答「不知道」：不要跳过。改用「启发式三选一」——给我三个具体选项让我指认（例如：❓这件事是每日晨会前做、还是每天下班前做、还是接到临时通知才做？），或者请我「举个上周刚发生的具体例子」。
- 我连续两轮都答不上来：换成更高视角的框架来启发我，至少尝试一种——
  · 第一曲线 / 第二曲线：现在这条业务的增长靠什么？它的天花板在哪？第二曲线可能从哪长出来？
  · 创新战略：我们和同行比，哪些能力是我们有而别人没有的？哪些活是我们做得特别重、特别慢的？
  · AI 原生战略：如果这个岗位从今天起只有一个人 + 一个 AI，哪些环节必须重做、哪些可以整段交给 AI？
  用这些框架问出 2-3 个能落地的新线索，再落回 A-E 的检查表。

【第 3 步：更新底稿并宣布达标】
每问完一轮就增量更新 storage/docs/company-diagnosis.md（保留原内容，补充新信息，勾掉已补齐的待确认项）。
当 A-E 全部达标、F 项你确认「仅凭底稿能无猜写出 8 条选题」时，停下来向我汇报：「底稿已达标，可以出选题清单。」并给出：体检表最终版（哪些从待补变成了达标）、底稿新增了哪几节、以及你现在最想先挖的三个岗位/工作流。

【铁律】
- 不要为了「显得达标」而放宽标准；宁可多追问两轮。
- 不要替我编答案：我问不出来就标「当事人也没说清」，这本身就是一条重要发现。
- 全程只问业务问题，不问我技术选型。

《企业诊断底稿》已达标（storage/docs/company-diagnosis.md）。现在基于它挖掘 AI 落地场景选题，并生成可视化选题清单上线，全部由你自动完成。

【第 1 步：读底稿，锁定高频事件】
通读 company-diagnosis.md 全文。把「重复高频事件清单」作为主矿脉——每条高频事件都是一个潜在选题的来源；再用「依赖知识」和「结果目标」判断这件事能不能被 AI 接管。不要引入底稿之外的通用模板场景。

【第 2 步：挖掘选题场景（至少 8 条）】
按「输入 → 处理 → 输出」框架，从高频事件里挖出至少 8 个 AI 落地场景。涵盖但不限于：内容生产、数据整理、客户沟通、内部流程自动化。
每条选题必须写明：选题名称、源自底稿的哪条事件（引用原句）、业务简述、输入材料类型、输出成果形式、处理步骤数、决策逻辑特点、以及一句话「为什么值得先做」。

【第 3 步：六维难易度评估】
用以下标准给每条选题打上 🟢 绿 / ⚠️ 黄 / ❌ 红：
1. 输入材料格式：🟢 纯文本（md/txt/csv）→ ⚠️ Office/PDF → ❌ 扫描件/音视频
2. 处理步骤数：🟢 少于 5 步 → ⚠️ 5-10 步 → ❌ 超过 10 步
3. 判断决策逻辑：🟢 规则清晰可量化 → ⚠️ 少量模糊需校准 → ❌ 大量主观经验
4. 输出形式：🟢 结构化数据/表格 → ⚠️ 简单图文排版 → ❌ 复杂报告/创意稿
5. 数据敏感等级：🟢 公开/非敏感 → ⚠️ 内部敏感需脱敏 → ❌ 核心机密
6. 业务重要程度：高 / 中 / 低
再补一列「**建议**」：绿多黄少 → 今天就做；红多 → 放二期，并说明一期先做什么。

【第 4 步：生成可视化选题清单网页并上线】
生成一个静态 HTML 页面作为选题清单（存为 topics.html），必须包含：
- 顶部标题：企业名 + 「AI 落地场景选题清单」；
- 每张卡片展示：选题名称、源自哪条高频事件、六维评分（绿黄红圆点）、评估说明、推荐理由；
- 支持按重要度（高/中/低）和难易度（绿/黄/红）筛选的筛选器（纯 JS，必须真实可用）；
- 底部标注推理假设与后续迭代方向。
然后用平台的静态前端发布规则把它上线（fmode-loop 的 Static frontend release）：
1. 注册/复用 Project：POST https://server.fmode.cn/api/functions（path=/fmode/project-register），拿 projectId；.fmode/deploy.json 已有且归属正确就复用。
2. 领取 STS：POST https://server.fmode.cn/api/apig/deploy/huaweicloud {token, projectId}，拿临时凭据与 obsPath；公开地址为 https://app.fmode.cn/dev/<projectId>/。
3. 上传 OBS：把 topics.html 与依赖资源传到 obsPath（前缀 dev/<projectId>/），-acl=public-read；.html 显式设 contentType: 'text/html'。
4. 刷 CDN：POST https://server.fmode.cn/api/apig/deploy/huaweicloud-cdn-refresh {token, projectId, path:"/dev/<projectId>/"}。

【第 5 步：汇报】
报出选题清单 URL：「选题清单已上线：https://app.fmode.cn/dev/<projectId>/topics.html，手机浏览器直接打开。」并附：你推荐的试点选题（1-2 条）与一句话理由、以及为什么其他几条建议放二期。

【铁律】
- 不伪造场景：每条选题必须能追回底稿里的具体事件，不能是通用模板。
- 发布流程不可跳过：必须走 STS → OBS → CDN。
- 筛选器必须真实可用，不是装饰。
- 最终访问地址必须是 app.fmode.cn 域名，不是华为云 OBS 桶域名。

我要做本体建模了，但先要把材料理清楚。我接下来会一批一批发材料给你（可能有图片、Word、PPT、聊天截图、朋友圈九宫格、视频、表格、以及一些打不开的二进制文件）。请你先读懂、归类、并告诉我缺什么。全程自动完成。

【第 1 步：先认材料】
逐个看每份材料：是什么类型、大概在讲什么、信息密度怎么样、对应我们选题场景里的哪个岗位/工作流。
遇到打不开的二进制文件：先看文件名、大小、头部特征判断它可能是什么；判断不了就标注「未知类型，建议我补充说明」，不要跳过，也不要猜里面的内容。

【第 2 步：归类到选题场景】
按我们选定的选题场景（见选题清单），把每份材料归到它服务的位置：
- 它是「输入侧」材料（资料进来要处理的原文）？
- 还是「规则侧」材料（报价规则、话术模板、合规要求这类判据）？
- 还是「样例侧」材料（历史上做好的成品，可以当 few-shot 范例）？
对应不上的材料，单独放进「暂无法归属」清单——这往往正是我们缺的那一块。

【第 3 步：给补充建议（关键的一步）】
基于实际材料，明确告诉我「还缺什么」，要具体到可执行：
- 缺哪一类材料（例如：缺最近 3 个月的真实聊天记录、缺一份完整的报价表、缺 5 份成品报告作为范例）；
- 每类建议找多少份才有代表性，为什么是这么多；
- 每类材料拿到后准备用来干什么（喂给哪个环节）。
写成一张《材料补充建议清单》，按「重要性」排序：先补哪几项，能补的补上，补不到的说清影响。

【第 4 步：写材料分析报告】
输出一份报告（写入当前项目 storage/docs/material-analysis.md），分四块：
① 这批材料讲了什么（按岗位/工作流分组，一段一个主题）；
② 每份材料归到哪个位置（输入侧 / 规则侧 / 样例侧 / 暂无法归属）；
③ 发现了哪些我们原来没想到的（新材料揭示的新情况、新材料暴露的旧假设错误）；
④ 还缺哪些信息（引用第 3 步的补充建议清单，按重要性排序）。
报告面向业务，用大白话写，技术名词第一次出现时用一句话解释。

【第 5 步：停下来等我确认】
把「材料盘点 + 补充建议清单 + 报告摘要」汇报给我，然后**停下**，问我：「这些材料够开工了吗？要不要先补几类？」我确认或补完材料后，你再进入本体建模。

【铁律】
- 不打码、不外传任何隐私信息；涉及真实姓名/联系方式的材料，报告里只写「已脱敏的某个对象」。
- 报告面向业务，不是技术文档——宁可多写一句解释，也不要堆术语。
- 材料里没有的，不要为了让报告好看而编出来。
- 不要在我确认材料之前就开始画本体图。

材料已确认（storage/docs/material-analysis.md），现在开始业务本体建模。你要把这个场景拆成五层，全程自动完成，不要让我做技术选择。

【第 1 层：对象（有哪些东西）】
列出这件事里所有的「东西」——人 / 事 / 物。逐个给出：对象名、一句话定义、它由谁维护。
特别注意找出「看起来是一个、其实是两个」的对象（例如「客户」与「联系人」、「订单」与「交付」），明确指出并说明为什么必须分开。

【第 2 层：关系（它们怎么连）】
说清对象之间的连接：一对一 / 一对多 / 多对多，以及关系的方向（谁引用谁）。
每条关系写一句中文注解，说明「这个连接在业务上意味着什么」。关系说不清的地方，标「待确认」并写清要问谁。

【第 3 层：规则（什么情况下发生什么）】
把业务规则列出来：状态怎么流转（状态机）、每次流转的触发条件是什么、谁有权触发、流转后发生什么。
区分「硬规则」（必须遵守，例如合规、审批）与「软规则」（经验判断，例如优先联系谁）。软规则要注明「现在靠谁的经验」。

【第 4 层：SOP（把事情从头到尾串一遍）】
把这个场景的标准作业流程写成步骤表。每一步必须写清五列：
| 步骤号 | 谁来做（岗位） | 做什么（动词+对象） | 输入什么 | 产出什么（交付物） |
步骤要完整覆盖：从什么事触发它开始，到最终交付给谁结束。

【第 5 层：SOP 步骤详解（重点写协作流转）】
逐个步骤展开，重点写清跨边界的地方：
- **谁提需求**：这一步的输入是谁提出来的？他为什么提？他期望拿到什么？
- **谁拿结果**：这一步的产出交给谁？他拿去做下一步的什么？
- **跨部门 / 跨上下级 / 前后阶段的交接**：交接时以什么为准（文件？系统记录？口头？群消息）？交接有没有容易掉球的地方？
- **卡住的后果**：如果这一步没按时做完，会影响下游谁、影响多大？
- **依赖的知识**：这一步要干好，需要哪些资料、模板、规则、历史案例？

【出图与产出】
1. 用 PlantUML 画一张对象关系图（类图 @startuml），字段写在类里、关系写在连线上，每一处都配中文注解说明「这是什么、为什么这么连」；
2. 用 PlantUML 画一张 SOP 流转图（活动图），把「谁提需求 → 谁处理 → 交给谁」的接力关系画出来；
3. 把 SOP 步骤表与步骤详解写成 markdown。
三份产物都写入当前项目，路径与文件名由你决定（建议 storage/docs/ 与 docs/design/），并在汇报时给出路径。

【汇报】
把对象清单、关系图、SOP 步骤表摘要、以及你标记的「待确认」项一起给我，问我一句：「这张图讲的就是你们公司的情况吗？有要补的对象、关系或步骤吗？」我确认后再进入下一步。

【铁律】
- 报告不要堆技术术语，多用中文注解和直观示意图；不懂技术的人要能一眼看懂。
- 不确定的地方明确标「待确认」，不要编一个看起来合理的答案。
- 除业务问题外，不要问我任何技术选择。
- 不要省略协作流转那一层——只画对象不写交接，等于没做本体建模。

把前面几节的成果收成一份《数据本体分析报告》，作为本阶段的交付物。全程自动完成。

【报告定位】
读者是**不懂技术的业务负责人**（老板、部门经理、岗位骨干）。所以：
- 图要多：对象关系图、SOP 流转图、状态流转图，能画图的地方不要用文字堆；
- 注解要足：图上每一处、每张表每一列，都用中文写清「这是什么、为什么这么设计」；
- 术语不过夜：必须出现的术语（对象、关系、SOP、状态机）在第一次出现时用一句大白话解释。
不要把这份报告写成技术设计文档——那是下一章的事。

【报告结构（四块，缺一不可）】
① **数据本体架构**
   - 对象清单：每行「对象名 / 一句话定义 / 谁维护 / 关键属性」；
   - 对象关系图（PlantUML 类图 @startuml）：字段写在类里、关系写在连线上，每个类和每条线都配中文注解；特别标出「看起来是一个、其实是两个」的对象；
   - 规则说明：硬规则与软规则分开列，状态机用一句话一句状态写清楚（从什么状态、满足什么条件、转到什么状态、谁触发）。
② **SOP 详解**
   - SOP 步骤表：| 步骤号 | 谁来做 | 做什么 | 输入 | 产出 |；
   - 步骤详解：逐步展开，重点是输入从哪来、产出交给谁；
   - SOP 流转图（PlantUML 活动图）：把接力关系画出来。
③ **协作衔接流程**（本报告的重点）
   - 谁提需求：一条需求从谁那里发起、为什么发起；
   - 谁拿结果：每个产出最终落到谁手上、他拿它做什么；
   - 跨部门衔接：部门 A 交到部门 B 时以什么为准（文件 / 系统记录 / 群消息），哪一步最容易掉球；
   - 跨上下级衔接：哪些步骤要上级审批、哪些下级可以自决；
   - 前后阶段衔接：上一阶段完成到什么程度才算可以进入下一阶段（准入门槛）。
④ **材料附录**
   - 本次用了哪些材料（原始文件名 + 类型 + 一句话内容）；
   - 每份材料归到本体的哪个位置（输入侧 / 规则侧 / 样例侧）；
   - 哪些材料没找到、影响是什么（诚实列出，不要掩饰）。

【产出与汇报】
报告写入当前项目（建议 storage/docs/ontology-report.md，供人阅读的版本），配图用 PlantUML 源码块内嵌（不要只给图片链接）。
汇报给我：报告路径、四块各自的完成度、报告里你标了哪些「待确认」项、以及你建议下一章先设计哪个对象/流程。

【铁律】
- 报告面向业务，不面向工程师；宁可多一张图，不要多一段术语。
- 有一说一：材料里没支撑的结论，标「基于推断，待验证」，不要写成既定事实。
- 隐私信息只写「已脱敏的某个对象」。
- 不要为了报告好看而补编对象或流程。

材料与本体报告都已就绪（storage/docs/ontology-report.md）。现在请你扮演一位严格的咨询顾问，对我这个看板项目做一次「追问式需求挖掘」。目标：把我脑子里「大概是那样」的需求，问到「每一项都具体、可开工、无歧义」。规则如下：

【工作方式】
1. 把待定的事画成一棵「决策树」：每个决定分出它依赖的下一层决定。
2. 分轮提问：每一轮，只问「现在就能确定答案」的问题（前置条件已经清楚的那些）。前置条件还没定的，留到后面的轮次，不要提前问。
3. 每个问题都要带上你自己的建议答案和一句理由，格式：
   ❓ 问题：<问题内容>
   ➡️ 我的建议：<建议答案 + 一句为什么>
4. 一轮问完就停下等我回答，不要自问自答；我的回答会改变决策树，你再算下一轮该问什么。
5. 能自己从我前面给的材料与本体报告里查到答案的，不要问我——先自己查，查不到再问。
6. 用大白话问。我是业务负责人，不是产品经理；问「谁每天要打开它」而不是问「用户角色权限模型」。

【要覆盖的方向】
- 目标与边界：这个看板到底给谁用、要回答什么问题、明确不做什么？
- 业务口径：本体报告里的对象/状态，哪些要做成页面、哪些只做筛选维度、哪些压根不上面？
- 关键提醒：什么情况最要命（例如快到期、超预算、久未跟进）？这些要不要顶到最上面？
- 数据来源：每个页面上的数字从哪来？如果某个来源断了怎么办？最坏情况是什么？
- 边界情况：数据量涨 100 倍怎么办？出现重复或错误数据怎么办？谁能看、谁不能看？
- 协作衔接：本体报告里「谁提需求、谁拿结果」那条链上，看板要帮哪一段？

【收尾（当没有待定项时）】
1. 把所有已定的决定，逐条列成清单；
2. 列出仍然开放的和明确不做的；
3. 给我一份《看板内容结构》：有哪些页面 / 每个页面放什么 / 有哪些筛选条件 / 有哪些统计数字 / 详情页展开什么；
4. 问我一句：「都对齐了吗？可以开工，还是要调整？」

【铁律】
- 不要在我确认之前就开始动手做；
- 不要太好说话：如果哪一块我看着含糊，就继续追问；
- 用我的语言（中文）提问，不要用产品术语和我绕。

我们已经完成企业诊断与业务本体建模。现在走「分支② 超级应用 · 自主进化」路线：做一套 To C 应用 + 管理后台。这一步只挖 C 端需求，不写代码、不设计后台。

【第 1 步：先问清 C 端定位】
分轮问我，每轮最多 2 个问题，先复述确认：
1. 这个应用给谁用？（一句话说清目标用户与他们的处境）
2. 用户第一次打开它，是为了解决什么事？打开后 30 秒内应该看到什么？
3. 它和我们现有的什么渠道 / 业务是什么关系？（替代 / 补充 / 引流）

【第 2 步：竞品与参考】
4. 有没有对标的竞品或你喜欢的同类产品？请列出 2-3 个，并说清「你喜欢它哪一点」。
5. 有没有可直接参考的页面 / 截图 / 链接？如果有，我等下会发给你。
（若我暂时给不出，就基于目标用户给出 2-3 个方向供我选，不要停下来等。）

【第 3 步：入口与业务逻辑索引】
6. 用户从哪里进来？（扫码 / 分享链接 / 公众号 / 搜索 / 线下物料）
7. 进来后的第一屏是什么？主路径是哪几步？用户在第几步最容易流失？
8. 需要登录吗？用什么方式登录（手机号验证码 / 微信 / 免登录体验）？

【第 4 步：点击体验（这一节最关键）】
9. 主流程逐步走一遍：用户点哪里、看到什么、下一步点什么——请把每一步写成「点击 → 看到 → 可做什么」。
10. 哪些地方必须有即时反馈（加载 / 成功 / 失败 / 重试）？哪些操作不可逆、需要二次确认？

【第 5 步：功能模块清单】
11. 这个 C 端一共几个功能模块？每个模块解决用户什么需求？请给每个模块一句话定义。
12. 哪些是「必须有」，哪些是「可以二期」？请明确圈出本期范围。

【第 6 步：输出《C 端需求纪要》】
写入 docs/prd/consumer-app.md，包含：
- 目标用户与一句话价值主张
- 竞品与参考（含「为什么参考它」）
- 入口与主路径（含流失点）
- 「点击 → 看到 → 可做什么」逐步体验表
- 功能模块清单（本期 / 二期）
- 三条可测的验收标准（能真实点开验证的）

写完后问我「C 端需求是否确认」，我确认后再进下一步（B 端管理后台）。不要提前写代码。

C 端需求已确认（docs/prd/consumer-app.md）。现在挖 B 端管理后台需求——后台是给「我们的人」用的，重点不是好看，是能管住。

【按顺序问，每轮最多 2 个问题，每个问题都带你的猜测版答案】
1. 谁用后台？有几种角色？每种角色分别能看什么、能改什么？
2. C 端产生的哪些数据必须进后台？（用户 / 订单 / 内容 / 消息 / 日志）
3. 后台最常用的三个操作是什么？（例如：审核、发货、改价、回复）
4. 哪些操作必须留痕（谁改的、改了什么、什么时候）？哪些操作必须二次确认或走审批？
5. 有没有「绝对不能给运营看」的字段？（例如成本、手机号全量、内部备注）
6. 后台要不要统计？要哪几个数字？每个数字的口径是什么？
7. 数据量大概多少？（决定要不要分页、搜索、导出）
8. 出问题怎么兜底？（误删能否恢复、批量操作上限、异常告警给谁）

【输出《B 端管理后台需求纪要》】
写入 docs/prd/admin-console.md，包含：
- 角色 × 权限矩阵（能看 / 能改 / 不能碰）
- 核心对象与状态流转
- 三个高频操作的完整流程（含确认、留痕、失败处理）
- 统计数字与口径
- 安全红线（敏感字段、导出限制、操作留痕）
- 三条可测验收标准，其中必须有一条是「越权必须被拒绝」

写完后问我「后台需求是否确认」。不要提前写代码。

C 端与 B 端需求都已确认（docs/prd/consumer-app.md、docs/prd/admin-console.md）。现在同时开工，用 Fmode（Fmode Code）开发并上线。

【第 0 步：确认用的是官方两个库】
前端统一使用（先读 README 与目录约定，再动手）：
- 界面：`@fmode/skill-code-lit@1.0.0`（源码 github.com/fmodecn/skill-code-lit）
- Agent 能力：`@fmode/skill-code-agent@0.1.1`（源码 github.com/fmodecn/fmode-code-agent）
C 端与 B 端**共用这两个库**，不要各用一套。

【第 1 步：先出技术合同，不写业务代码】
- docs/schema/data-model.md：C 端与后台共用的数据模型（实体、字段、关系、tenant/owner、状态流转）
- docs/api/functions.md：普通 CRUD 走 Parse；特权逻辑走 Functions（鉴权、租户校验、幂等、稳定错误码）
- 明确写清：客户端不得持有 masterKey、平台 session 或数据库 URI

【第 2 步：先 C 端，再管理后台（顺序不能反）】
1. 按《C 端需求纪要》做出 C 端全部页面与主流程，含加载 / 空 / 错误 / 重试 / 禁用状态；
2. C 端能跑通后，再做管理后台：登录鉴权、列表与筛选、三个高频操作、权限矩阵、操作留痕；
3. 两端共用一套数据模型，不要各写一套；C 端数据要能实时进后台。

【第 3 步：各自自测（要真实点击，不要只看代码）】
- C 端：手机尺寸下把主路径完整走一遍，并故意制造一次失败看提示；
- 后台：三个角色各登录一次，验证「能看的能看、不能看的拒绝」；越权请求必须返回拒绝，而不是返回空数据。

【第 4 步：提交与发布上线】
1. 提交 Git 私有仓库，commit 写清这一版做了什么；确认无凭据、无本地绝对路径。
2. 注册 / 复用 Project：POST https://server.fmode.cn/api/functions（path=/fmode/project-register），确认归属。
3. 构建：public path 设为 /dev/<projectId>/，产物根必须直接含 index.html。
4. 领 STS：POST https://server.fmode.cn/api/apig/deploy/huaweicloud → 上传 OBS（前缀 dev/<projectId>/，-acl=public-read，.html 显式设 text/html）→ 刷 CDN。
5. 报出 C 端地址与后台地址（同一 Project 下不同路由即可）。

【验收】
- C 端：手机能打开，主流程走通，失败态有明确提示；
- 后台：三种角色权限正确，越权被拒，关键操作有留痕；
- 两个地址都是 app.fmode.cn 域名，不是 OBS 桶域名。

【铁律】
- 本路线到「上线」就结束：不做技能封装、不做复盘报告。
- 不伪造成功：任一步失败，如实报告卡在哪、下一步怎么办。
- 不打印任何凭据、token、masterKey、STS。

按我们确认的《看板内容结构》开工，做一个可以打开、可以点的看板，然后写好文档、提交 Git、发布上线。全程自动完成。

【第 1 步：先定数据模型，再写界面】
把《数据本体分析报告》里的对象 / 关系 / 规则落成后端的表 / 字段 / 关系（写进 docs/schema）。每张业务表都要有归属与权限校验，别把接口开成谁都能改。先把模型定死，再动界面——顺序反了会反复返工。

【第 2 步：技术栈硬要求 —— 必须 Fmode（Fmode Code）】
- 前端**统一使用官方两个库**，不要换成别的方案：
  - 界面：`@fmode/skill-code-lit@1.0.0`（源码 github.com/fmodecn/skill-code-lit）
  - Agent 能力：`@fmode/skill-code-agent@0.1.1`（源码 github.com/fmodecn/fmode-code-agent）
  先读它们的 README 与目录约定再动手；按库自带的结构与构建方式初始化。
- 遵循 Fmode 约定的项目结构（页面/组件/服务分层），业务逻辑放 service，组件只负责展示。
- 后端按已落盘的云服务资源：浏览器端普通数据读写用 Parse SDK（配置里的 appId + serverURL）；特权逻辑走 functionsURL 云函数。

【第 3 步：前端设计感要求（这一条要认真做）】
- **紧凑布局**：信息密度要高，不要大片留白；一屏尽量多放有用信息，列表行高、表格间距都按「后台工具」的密度来，而不是按落地页的稀疏来。
- **内容丰富**：每个页面都要有实在内容——概览页要有几个关键数字卡片 + 趋势 + 待办/预警区，列表页要有筛选条 + 分页 + 排序，详情页要把关联对象（参考本体报告里的关系）都展开。
- **第三方库**：用成熟的 UI 组件库 / 图表库把界面撑起来（表格、日期选择、图表、图标、消息提示都用现成的），不要手搓基础组件。
- **漂亮**：统一的配色与间距体系，浅色为主，状态用颜色区分（正常/警告/危险），空状态与加载态都要有设计，不要出现「白屏 + 一堆文字」。

【第 4 步：做四类页面】
1. 列表页：能看全、能翻页、能排序；
2. 筛选页：按我们确认的筛选条件（时间 / 状态 / 分类 / 关键词）组合过滤；
3. 统计页：把确认过的统计数字做成几块可视化（数量 / 趋势 / 占比），每个数字标明它的口径是什么；
4. 详情页：点开一条记录，展开它的属性和相关的记录（例如一个客户下面的所有沟通与订单）。

【第 5 步：用模拟数据跑通，并明确标注】
后端先填一批模拟数据，让每个页面都有东西可看。所有模拟数据必须**明确标注「模拟数据」**——包括页面角标、每条记录的标记，让人一眼能分清哪些是真的、哪些是演示的。绝不把模拟数据伪装成真实数据。

【第 6 步：写 README（交付物 + 项目描述）】
在项目根写 README.md，必须包含两块：
1. **产出物清单**：线上地址、Git 地址、技术栈与版本、四类页面分别在哪个路由、用了哪些第三方库、数据模型概览（表名 + 一句话用途）；
2. **项目描述**：这个看板解决什么问题、给谁用、来自哪个本体报告、当前是模拟数据还是真实数据、下一步计划接什么。
README 要让一个没参加过课程的人也能看懂并接手。

【第 7 步：提交 Git 与发布上线】
1. 提交 Git：把项目源码（含 README）提交到 git.fmode.cn 的私有仓库，commit message 写清这版做了什么；确认暂存区没有凭据、token、本地绝对路径。
2. 发布上线（平台静态前端发布规则，逐步执行并各自校验）：
   a. 注册/复用 Project：POST https://server.fmode.cn/api/functions（path=/fmode/project-register），拿 projectId；.fmode/deploy.json 已有且归属正确就复用。
   b. 构建静态产物：**按 Fmode 构建要求把 public path 设为 /dev/<projectId>/**；产物根目录含 index.html；发布前自查无凭据、无 token、无本地路径。
   c. 领取 STS：POST https://server.fmode.cn/api/apig/deploy/huaweicloud {token, projectId}，拿临时凭据与 obsPath；公开地址为 data.url，格式 https://app.fmode.cn/dev/<projectId>/。
   d. 上传 OBS：用官方 OBS 客户端把产物传到 obsPath（前缀必须是 dev/<projectId>/），-acl=public-read；.html 显式设 contentType: 'text/html'。
   e. 刷 CDN：POST https://server.fmode.cn/api/apig/deploy/huaweicloud-cdn-refresh {token, projectId, path:"/dev/<projectId>/"}。

【第 8 步：汇报】
向我报出三样东西：「线上地址：https://app.fmode.cn/dev/<projectId>/」「Git 地址：<仓库地址>（commit <sha>）」「README 路径」，并说明：四类页面分别在哪、筛选有哪些维度、统计数字的口径、模拟数据标在哪里。然后问我「要不要现在接真实数据源」。

【铁律】
- 前端必须 Fmode，不要擅自换框架；窗体大改前先问我。
- 模拟数据必须处处有标记，不可与真实数据混淆。
- 不出现任何凭据、密钥、内网地址；最终访问地址必须是 app.fmode.cn 域名，不是 OBS 桶域名。
- 打不开的页面不要报「已完成」，如实说哪里卡住了。

你是我的专属数字分身。这是「收尾」全流程指令：把运行环境装好、自检上线、建好数字 DNA 档案，并接手我刚做完的项目。全程自动完成，除验证码 / 手机号 / 姓名外，不要让我做任何操作。

【第 1 段 · 环境初始化】
1. 安装 / 升级 Fmode Loop 技能：从 https://repos.fmode.cn/x/fmode-studio/skills/fmode-loop/install.mjs 下载官方安装器，校验线上 manifest 与每个文件的 SHA-256，运行 node install.mjs --dir 用户级全局技能目录 --profile all。安装器不可用时，备选 npm install --global fmode-loop，再运行包内 install.mjs 做同样校验。本机已有 fmode-loop 不许直接复用：以线上 manifest 为准逐文件校验本地版本，不一致或缺文件就先备份旧目录再覆盖安装，只动 fmode-loop 目录、不碰其他技能。装好后读取 SKILL.md，确认能加载。
2. 平台登录：有 sessionToken（~/.fmode/config/user.json）就直接复用；没有或已过期，才向我要手机号 → 发验证码 → 完成登录并保存。凭据不出现在聊天、日志或仓库里。
3. 开通并落盘云服务资源：POST https://server.fmode.cn/api/fmode/enterprise/subscription/status（参数 sessionToken）确认会话有效；若平台提示企业资源未开通，按技能里的企业开通流程自动领取（需要姓名时向我要姓名）。开通后把本机云服务资源落盘到 ~/.fmode/config/enterprise/current.json（含 appId / serverURL / functionsURL；masterKey 只在这份受保护配置里，目录 0700 / 文件 0600）。不让我触发控制台开通，也不让我粘贴配置内容——由你基于 trial-standalone 返回的 backend 自动完成。
4. 上传通道约定：单个文件 / 单页报告优先走免密钥 S3 通道（skill-storage 的 uploader.mjs put，公开地址 https://s3.fmode.cn/user/<你的id>/）；只有「前端项目正式发布到 app.fmode.cn/dev/<projectId>/」才走 STS→OBS→CDN。STS 领取失败不要卡住，单文件 / 报告用 S3 一样能拿到公开 URL。

【第 2 段 · 自检上线】
四项自检，全部自己完成，不许向我索要凭据：
1. fmode-loop 技能能加载。若丢失：不要自己重装，直接回我「初始化丢了，请把初始化提示词再发一遍」；
2. 平台登录有效：同上 subscription/status 接口验证；401 / 209 就自己按 fmode-loop 的验证码登录流程重新登录；
3. 云服务资源可读：~/.fmode/config/enterprise/current.json 存在且含 appId / serverURL / functionsURL；缺失就说「云资源没落盘，需要重新做一次初始化」；
4. 企微通道可用（本会话能正常收发消息）。
四项全过，回我一句：「我在。环境已就绪，云资源已就位。今天想让我先干点什么？」然后等我派活。

【第 3 段 · 数字 DNA 建仓建档】
1. 检查我的平台 Git 账号：没有就用 Gogs 代理流程（POST https://server.fmode.cn/api/functions，path=/gogs/admin/proxy，服务端按登录手机号派生用户名）自动创建，密码自己生成强密码并妥善保管，不展示给我。
2. 用个人 token 创建**私有**仓库，仓库名建议 digital-dna（被占用就加后缀）。
3. 写入数字 DNA 四件套：identity.md（你是谁、我是谁、职责、性格基调）；memory/summary.md（与我历史沟通的结构化摘要：大事记 / 偏好 / 在办事项，只写摘要不存逐字）；capabilities.md（当前能力清单：已装技能、能干的活、各自触发条件）；sessions/session-init.md（本次初始化的完整对话记录）。另加 VERSION（版本号，每次实质变更 +1）与 README.md（常驻规则：本仓库是数字人的完整数字 DNA，存身份档案、能力清单、会话归档、任务记录与看板；凭据永不入库；每次完成我的任务后增量更新并提交）。
4. 一次性提交，commit message：「chore: 数字 DNA 初始化」；git log 确认后回我「数字 DNA 已建档：身份、记忆、能力、版本四件套齐了。」并给出 Git 面板免密链接：https://git.fmode.cn/login/token?t=<你的 Gogs Token>

【第 4 段 · 接手项目、建档案、带我读懂】
项目 Git 地址：<项目 Git 地址>（如果我没给地址，就先把第 1~3 段做完，然后提醒我补地址，不要猜）
1. clone 下来，在数字 DNA 里建一条「项目档案」，记录这个项目是什么、解决什么问题、我负责哪一部分。
2. 检查能否跑起来：依赖装得上吗、本地能启动吗。跑不起来的原因一条条列给我，不许自己糊过去。
3. 带我走一遍代码：数据模型在哪个目录、列表 / 筛选 / 统计 / 详情四类页面分别在哪个文件、后端云函数与契约在哪。用大白话讲，讲完让我自己复述一遍，我讲错了你纠正我。
4. 然后等我提第一个改动需求，改完重新发布上线，把地址给我。

【铁律】
- 全程自动：除验证码 / 手机号 / 姓名外不让我做任何操作；目录选择、失败重试、环境判断全由你完成。
- 不伪造成功：任一步失败，如实汇报卡在哪、下一步怎么办、预计多久。
- 不打印任何凭据、token、验证码、masterKey（Git 面板免密链接属于交付物，允许返回）。
- 凭据永不入库；完整对话按会话存入 sessions/，每条对话一个文件。

请按 https://skillhub.cn/install/skillhub.md 安装 @fmode/fmode-slide-design（安装时用 --dir 指向你的技能目录）；装完读它的 SKILL.md 和《快速上手》，按它自己的规范干活。

【第 1 步 · 先把这两天的「业务素材」收齐（不许编数字）】
只从业务视角捞事实与数字，逐项列清单：
- 我们面对的企业/团队：做什么业务、组织规模与岗位构成、现在最痛的环节
- 诊断覆盖：访谈了哪些部门/岗位、收集到多少条真实的业务事件（高频事件）
- 反复出现的业务问题：最要命的 3-5 条（带真实频次与影响面）
- 选定切口：先做哪一块、业务上为什么这么排先后（依据是什么）
- 现在的变化：原本靠人硬扛的重复工作，现在哪些由系统承接了
- 价值口径：省了多少工时/人力、减少了多少差错与返工、加快了哪个关键环节
- 方向：接下来 1-3 步要走的路
★ 技术性内容不进这份汇报：平台/工具名称、技术栈与组件、接口与文件路径、报错文案与排错过程、我们自己怎么调试与试错——一律不写；确需提及就压成一句业务话（如「由数字分身承接了重复性工作」）。
哪一项手上没有，就如实写「无」，不要拿示例数字凑。

【第 2 步 · 先定这 10 页的叙事，再出图】
主线是「业务 → 组织 → 企业价值 → 方向」，技术只作背景一笔带过。按下面结构依实际情况微调——**就 10 页，不多不少**：
- P01 封面：我是谁；这两天为谁、解决了什么业务问题（一句话价值主张）
- P02 业务起点：这家企业/团队在做什么、现状如何、卡在哪里（用业务语言）
- P03 组织视角：由哪些人 / 岗位 / 环节撑起来，哪些环节在靠人硬扛
- P04 关键发现：反复出现的 3-5 个业务问题（带真实数字与影响面）
- P05 切口选择：先解决哪一块、为什么这么排先后（业务判断）
- P06 现在的能力：哪些事已经能由系统承接（用「谁在做什么」的业务说法，不写技术栈）
- P07 效果与价值：省了多少工时/人力、减少多少差错返工、加快哪个关键环节（真实口径，不虚夸）
- P08 组织影响：岗位与协作方式的变化，谁受益最大
- P09 未来方向：接下来 1-3 步的业务路线图（不谈技术实现）
- P10 收尾：一句专家级金句 + 邀请
整体风格：浅色高级感、信息密度高、每页一个明确视觉焦点、文字层级分明；10 页共用同一套配色与元素语言（风格统一）。
**先把这 10 页的标题与每页要点写给我确认**，我说「可以出图」你再开始生成。

【第 3 步 · 出图（严格按技能规范）】
- 命令形态：`SKILL_IMAGE_OUTPUT=<输出目录> node fmode-image.mjs --slide "<完整prompt>" <名称>`（脚本就绪方式见技能 SKILL.md 的「生成流程」一节）
- 尺寸 1792×1024、模型 gpt-image-2.5-sunburst（技能内置）；**所有要显示的中文逐字写进 prompt**，并加一句「不得改写、不得增加文字」
- 并发不超过 3；每张出图前先检查文件已存在则跳过（断点续传）；单张失败重试 3-5 次、退避 8s×次数
- 分批跑（每批 6-7 页）+ 显式查缺 + 手动补跑；每张完成打印一行 `OK pNN (耗时) [done/total]`
- 出完逐页自检：色值泄漏、文字重影、错别字、多出来的英文口号或年份

【第 4 步 · 拼成 PPT 并交付】
- 用户确认风格后，用 python-pptx 拼成 16:9 PPTX（每页一张满屏图），同时保留单页 PNG 以便替换
- 上传拿公开链接，把「PPTX 链接 + 单页 PNG 目录」发给我
- 顺手把这份复盘归档进数字 DNA 仓库（projects/<项目名>/report/），提交一次

【铁律】
- 只有 10 页，不许多做；每页信息密度要高，不做空洞的大留白页
- 汇报只讲业务、组织、价值与方向：**不写平台与工具名称、技术栈、接口或文件路径、报错与排错过程、内部试错记录**
- 某一页若只能用技术语言说清，就改写成「这给业务带来什么」
- 不要「深色底 + 程序贴字」那套，一律整页 AI 设计图
- 所有数字必须来自这两天真实产物，编造即视为失败
- 不打印任何凭据、token、masterKey；最终链接必须公开可访问