适用：CradleMC 策划、开发人员、投稿作者与 Wiki 编辑者。2026-11-02 建立并按专题化任务修订。
本页是唯一权威现行规范；原开发文档路径仅保留迁移提示。
这是公开编辑规范，不是新功能公告；虚构示例不构成开发计划。依据本阶段负责人明确授权整理，作为后续策划日志任务的默认写作参考；新增业务内容仍须审核。
目的与栏目边界
用专题文章向玩家解释已经允许公开的设计动机、核心机制、预期体验及真实进度。每期围绕一个功能或一次机制调整，不把十几个无关改动拼成接口说明书。中文为主，语气自然、亲切、专业。
| 栏目 | 回答的问题 | 收录条件 |
|---|---|---|
| 更新日志 | 实际改变了什么 | 有已发生变更证据，注明源码记录还是实际上线 |
| 路线图 | 方向与进度是什么 | 状态有依据；已规划须有团队决策，不凭TODO认定 |
| 策划日志 | 为什么这样设计、玩家会如何体验 | 获准公开的主题与正文，不能用叙事制造新承诺 |
信息可由获批计划进入路线图，再以日志解释；上线后更新日志记录结果、玩家指南维护现行规则。无需机械同序，但规则正文只保留一个主要维护位置，其他栏目引用它。
四大专题与独立编号
| 专题 | 标识 | 主要范围 |
|---|---|---|
| 经济专题 | economy | 商品市场、贸易、价格、税收、货币、金融 |
| 战争专题 | warfare | 战争规则、战略、军事、领土争夺 |
| 工农业专题 | agriculture-industry | 农业、畜牧、采矿、工业制造与生产 |
| PvE专题 | pve | 探索、怪物、冒险、PvE挑战 |
这是栏目分类，不代表其中玩法已批准或上线。未来扩展专题需确认定位及标识。
每个专题独立从 #001 编号，全站不设连续期数。专题可交替发表；总目录按实际发布日期倒序，专题索引按本专题编号列文章，待审稿不列为已发布。投稿可预留编号，退稿或变更保留编辑记录，不因此宣称发表。
叙事方法
参考 Paradox Development Diaries 的专题组织方式：开场对话→设计问题→机制及取舍→玩家情境→进度与不确定性。这里借鉴的是写法，不复制其原文、图片或版式资产，不冒用 Paradox 官方身份，也不暗示合作。
正确：“本期解释已批准方案怎样减少操作步骤，具体费用仍在测试。”
不推荐：“革命性系统马上上线，保证解决所有问题。”
设计动机写真实问题与权衡，不替团队编造意图。技术细节只有在帮助玩家理解限制时才展开。每个示例给出起点、玩家操作、结果、条件；区分现行体验和未来假设。
采用经济专题投稿所体现的写作方向：真实开发者身份与玩家交流，先讲动机再讲机制，用玩家情境和演示表解释取舍；简洁、自然、专业，避免过度宣传、自赞和反复口号。此处只规定写法，不公开待审稿机制，也不表示该稿已通过审核。战争、工农业和PvE不必复制经济专题的章节名称。
标题、编号与署名
- 标题格式：CradleMC 策划日志｜经济专题 #001：主标题——副标题；其他专题替换专题名称，副标题可按主题需要设置。
- 标准路径采用
project/dev-diaries/专题标识/编号-英文短名。不同专题可同时拥有 #001；不是全站第001篇，也不是软件版本号。 - 投稿可预留本专题编号；未公开只标待审核，不进入已发布索引。不预建大量空文章。
- 日期同时记录发布日期和内容最后核实日期；不能将Git作者日期当服务器上线日期。
- 作者使用真实编辑身份；代表团队署名必须获授权。AI整理可以署“Wiki编辑整理（Codex）”，不能编造主技术已审签。
- 正文不再重复页面一级标题；标题由页面元数据展示。原始投稿可保留一级标题，入库排版时避免重复。
- 开头推荐依次包含本期主题、开发者问候、真实作者及所属策划小组、必要开发说明。原稿问候与正式发布日期不一致时由发布编辑核对，不在草稿阶段伪造日期。
- 作者身份不得捏造；结语不强制增加开发团队署名。
文章结构与写作要求
推荐主线为：设计动机→机制规则→玩家选择或实际影响→示例→结语。开场介绍本期主题；机制写清规则边界；示例标明演示假设而非正式参数；结语简要收束并说明必要后续工作。复杂主题可调整结构，不强制十个同名章节，但不能省略开发说明、状态和关键依据。
下一期预告必须标明专题，如“经济专题下一期预告：价格的形成——从买卖订单到市场成交”。这只是专题内预告，不表示全站下一篇文章，也不承诺日期。没有确定主题就不编造预告。
现行功能涉及费用和权限时，要有配置/代码依据及适用版本；未来设计以对应业务批准记录为依据，并明确未实现状态。投稿规则不自动成为已批准策划，策划讨论中的确认也不是团队批准或代码实现。未批准数值不写成正式参数，演示案例注明假设。技术方案有多个选项时标为待决策，不能替团队选定。
| 状态 | 推荐表述 | 不推荐 |
|---|---|---|
| 实服正式开放 | “在版本X、环境Y完成所列范围验收，开放情况为Z” | 无证据的“全面上线” |
| 已实现、待验证 | “提交X已有实现，本轮尚未实服验收” | “有类，所以可放心使用” |
| 开发中 | “已有开发记录，范围为X，未完成Y” | 把TODO当正在开发证明 |
| 已批准策划 | “团队记录X批准该方向；日期未定” | 作者自行承诺近期上线 |
| 个人构思/探索/待定 | “允许公开讨论的候选方向，不承诺实施” | 将未经公开批准的个人构想放进探索栏 |
| 暂缓/取消 | “因已确认原因调整状态，保留原文语境” | 悄悄删掉旧承诺 |
设计、开发、验证、实服开放分别记录。“已测试”须写明测试版本、环境、范围与结果；不等于已在实服开放。个人构思、已批准策划、开发中、已实现、已测试与实服正式开放不可合并成一个“已完成”。服务器启动不是全功能验收；默认值不是生产设置；文档获准公开不是修复完成。
图片、图表与原型
优先用项目授权资源或实际截图，去掉玩家隐私、坐标敏感信息、凭据和管理界面秘密。每张图注明素材来源/授权、日期/版本和类型：实机、UI原型、概念图。生成图只能明确标为概念示意，不能冒充实机。没有素材就用文字或简洁表格，不放失效图片。
沿用现有Wiki样式与标准Markdown，不新增CSS或内联脚本。图片提供替代文字和说明，避免只靠颜色表达状态；移动端用短表格，复杂关系可用Mermaid，但发布前验证渲染，不能把文本源码回读当图表通过。
正确：“界面原型，仅示意入口，布局和数值未定。”
不推荐：“游戏截图”，实际却是生成图或未实现原型。
投稿、审核与发布流程
按“选题→策划写作→业务审核→主技术确认→编辑审核→发布授权→发布→结果核验”推进：
- 选题确认专题、编号及可讨论范围；个人构想不得以探索标签绕过审核。
- 策划写作保留作者原稿，明确设计动机、机制、示例和开发说明；编辑只在获授权范围改动。
- 业务审核核对市场边界、费用、税收等实际设计决定，记录结论及未决项，不能由排版替代业务裁决。
- 主技术确认实现状态、可行性、接口/数据和安全限制；核对提交、配置、测试，不公开敏感故障步骤。记录真实审核人/日期/范围，不捏造审签。
- 编辑审核核对专题编号、标题、身份、问候日期、下一期专题、图注版权、排版与有效链接。
- 单独取得对应正文及素材的公开发布授权。文章审核通过不自动等于获准公开发布；常规编辑权限不是新承诺批准。
- 发布前读取路径/最新版本，备份已有内容；新建防冲突，更新用最新baseVersionId。上传素材后只使用工具返回并已核验的真实地址。
- 回读完整正文、元数据和状态，检查链接、匿名可见性及素材访问；浏览器视觉/移动端另验，保留未验证项。
草稿或投稿状态必须有真实访问控制证据。仅改标题、隐藏导航或工具返回状态值不能证明保密。若工具不能创建非公开稿或不能核验访问控制，保留仓库外源文件，不冒险公开创建。
公开规范不得含内部批注意见、联系人或秘密；没有可靠访问控制的内部意见只保留本地。
更新、勘误与历史保留
保留原发布日期和期号，新增“截至日期的状态说明/勘误”，注明改变了什么、证据和对应路线图。实质规则变更不能无声重写历史；重大错误显著更正并链接当前指南。取消也保留说明，不倒填历史日期。勘误不是发布新规则的快捷通道。
完整 Markdown 写作模板
下面为编辑骨架，实际发布前替换全部占位、移除不需要的章节并取得审核。不可直接将空模板发布为一期文章。
专题：经济/战争/工农业/PvE
本专题编号：#NNN（可预留待审，不是全站期号）
标题：CradleMC 策划日志｜经济专题 #NNN：主标题——副标题
本期主题：……
发布日期：待批准，正式发布当天填写
内容最后核实：YYYY-MM-DD
作者：真实姓名/笔名
所属小组：真实策划小组，未确定则不捏造
开发者问候：与实际发布日期一致；草稿保留原稿并记录编辑提醒
开发说明：未来设计、当前实现与开放状态分开
适用状态：个人构思/已批准/开发中/已实现/已测试/实服开放，分项说明
依据：审批记录、Git提交、配置与验证记录
## 本期导语
用自然语言向玩家说明本期唯一主题；不要把预期写成事实。
## 为什么考虑这个设计
说明已确认的问题、目标和取舍；区分团队决定与作者建议。
## 核心玩法与边界
规则一：……
规则二：……
费用、权限、数据安全和未定事项：……
## 玩家情境
给出输入、操作、结果和限制；尚未实现的演示明确使用“假设/示意”。
## 界面与配图
素材：待提供；来源/授权：待核对；对应版本：待填。
说明：实机截图/原型/概念示意，不能混用标签。
无可靠素材时删去占位，不发布空图或伪造实机图。
## 已确定与待调整
已批准：……
已实现：……
尚待验证：……
仍未定案：……
## 开发进度与下一步
写已获准公开的工作及验证目标；没有批准的日期就不写上线时间。
下一期主题未确定时不预告。
## 相关资料
路线图条目、最终玩家指南、更新日志和来源；只为已存在页面生成链接。
## 结语与本专题下一期预告
简要收束，不强制团队署名。
[专题名]下一期预告：已确定主题；未定则删除，不承诺日期。
## 编辑记录
日期、修订原因、影响状态、勘误或取消说明。
业务审核：待填写；主技术确认：待填写；编辑审核：待填写；公开发布授权：待填写。
虚构示例：纸上导览卡（纯写作演示）
以下全文为虚构示范，不是CradleMC真实开发日志，不构成正式开发承诺；没有立项、实现或上线日期。
标题示意：CradleMC 策划日志｜工农业专题 #NNN：让纸上路线更容易阅读
发布日期：不适用（练笔）
作者：编辑规范示例，非团队公告
状态：虚构；最后核实日期不适用。
为什么讨论这张卡片
假想一个完全虚构的练习场景：读者每次看纸上路线都要在两张纸之间往返寻找说明。我们想用这段示例展示“先说问题，再说机制”的写法，而不是声称项目需要或正在制作导览卡。
一个可以讨论的演示机制
在这个虚构方案里，纸面上方放主题，中间放三步路线，下方说明限制。这样读者先看目标，再看行动。它仍有取舍：文字变短后可能缺少细节，因此要给更多说明留位置。此段只演示如何解释设计权衡，不涉及真实游戏功能。
读者情境与未定事项
假设读者拿到这张练习卡，先读目标、再选择一步、最后核对限制。所有数字、界面与结果都只是文字练习，尚无原型或实机图，不附假截图。
进度与结语
没有开发进度、团队批准或下一期预告。若未来有人把练习转成真实方案，仍需重新立项与公开审核。本示例到此结束，不是功能预告。
发布前自查清单
- 主题公开批准与正文批准可追溯，未把个人构想写成计划。
- 期号、日期、署名真实；设计/开发/验证状态分列。
- 机制、数值、费用、权限与提交和配置一致。
- 未公布内容、故障利用步骤、凭据和隐私已排除。
- 情境不暗示未获批上线，图片授权和类型清楚。
- 关联页面已经存在，链接与渲染、匿名访问已核验。
- 勘误记录、旧稿备份与回读记录齐全。
- 首次公开未来功能已获明确发布批准，剩余验证如实标明。
专题入口与修订记录
经济专题、战争专题、工农业专题、PvE专题、策划日志总目录。
2026-11-02专题化修订：由旧开发文档规范迁入本栏目；全站统一期号改为专题独立编号，补充投稿身份、专题预告和八步审核/发布流程。旧页只保留迁移提示，历史版本仍可追溯。图片授权、安全、访问控制、版本备份、事实与验收区分、虚构示例及历史勘误要求继续有效。
来源与栏目关联
依据：2026-11-02项目负责人第六阶段任务及新增写作规范授权；Paradox风格指该任务确定的叙事要求，不是第三方资产授权。规则以本公开规范为后续默认参考，业务内容不能由模板自动批准。
阅读：更新日志、开发路线图。