园丁手册

花园宣言 回答「为什么」和知识如何流动；这份手册回答「怎么做」。入口是首页 index.md（公开站即 www.digiinfr.com/kb）。手册本身也按花园的规则生长：

所有参与作业的园丁按这个顺序用：

1. 「我们认同什么」——写之前的判断基准，不是装饰；
2. 「一、写给谁，收什么」——决定做不做；
3. 「六、每天怎么干」——步骤；
4. 「五、笔记怎么写」——格式、拆篇、成熟度、标签；
5. 「七、合入与修剪」——出门。

改首页或导览时才看第二节。互链和中文规则每天都用。

我们认同什么

写笔记时的判断基准。结论不要和这些对着干。

1. 组织目标决定资产管理目标。 行业、规模、阶段定位不同，组织的目标就不同，对应资产管理的方式与资产关注的重点就完全不同。
2. 「管资产」没有标准，因组织形态而异，「管设备」相对标准化。 方法与管理体系（包括组织架构分工、资产分类、治理模式）跟着形态走；设备运维的方法可能相对共用。
3. 资产管理最大的难点在于要跨组织协调。 包括不同职能组织（部门），也包括不同层次的组织（如集团与下属单位）。
4. 分重点，有策略、有针对性地持续改善。 无论是数据初始化，还是持续运营，都先看明白当前的重点是什么，有计划地先把重点做好，再持续优化。
5. 永远在成本、风险、性能之间权衡。 没有一种模式绝对最好，先进意味着更难、更贵。
6. 资产主数据是一切的基础。 工作量大，有历史遗留问题是常态；不要指望一次性整体变好，要靠常态化的组织机制有计划地改（区分重点、持续改进）。
7. 最终要做到全周期、全品类、全价值。 从规划到形成资产，再到使用、维护、退出；品类不限于设备（还可能包括无形资产、股权投资、不动产……），价值同时看成本与收益。
8. 专业化分工，按类型差异化管理。 组织架构与治理模式要支撑专业归口；不同类型的资产，需要有专业的归口组织进行专业化管理。全局资产管理部门要协调到专业归口，不要把专业归口管理与资产使用管理混同。
9. **在中国，合规与穿透是硬约束。
10. 系统是最佳实践的载体，也是风险控制的工具。 最大作用是帮人找到管理的重点与抓手；先理解业务模式与管理需求，才有系统进行固化与支撑。

写导览或笔记前，请先完整过一遍本节信条。 引用时务必按条号引用，不要另造第二套标准，不要与 花园宣言 打架。

花园怎么活

下面几条每天都要用。展开与修辞回 花园宣言，这里只钉可执行的含义。

开着门工作。 领域里的方法与智慧，本身没有什么可保密的；真正难的是付诸实践（与 花园宣言 同口径）。种子即可公开；等待完美，往往等来的是沉默。半熟可以公开，客户名和内部作业不可以。内容不是定论，是当下的最佳理解：发现更好的就更新，错了就改正。笔记用 updated 记日期；纠错在正文用一句说清旧说与新说，不在每篇笔记里开修订节。手册和宣言才写修订记录。

花园不是档案馆。 连接比归类更重要：笔记靠链接相遇，不靠目录树分类。标签是一套轻坐标（主题、环节、行业、规模是必要的），沿自己的线索走进来；同一篇笔记出现在多条路上。路是走出来的，再铺——不预设完备分类，幼苗不急着挂上首页主题簇和导览，但标签要打。

中立、诚实、可修剪。 讲清适用与局限，不夸大、不夹带推销。引用注明出处，案例隐去可识别的企业与个人。过时的标注，重复的合并，离题的从入口和导览摘掉。花园真正的果实结在花园之外。

不断修剪。 发现更好的做法就改，并说明为什么。两篇打架就改其中一篇，不靠读者猜：知识如何流动以宣言为准；收什么、怎么写、怎么合入以本手册为准。

一、写给谁，收什么

写给懂行的人。 读者从资产管理出发：在岗、划责、或推动组织形态变革，以及为这些业务建系统的人。三条路是同一视角下的不同课题，不是三种读者、三套口吻。他们有起码的基础（偶有新人，也不为零基础写），缺的是自己组织之外的见识。真正值钱的内容是：别人怎么做、坑在哪、判断依据是什么、边界怎么划、数字基准多少。通行概念不科普；解释只留给两处——词义在职能之间真会歧义（如「资产」），和与直觉相反的结论。

收方法，不收产品。 收录业务的方法、道理、坑与判断依据；不含任何软件的功能介绍和操作说明。对业务理解得越深，系统才越好用。系统类笔记只写业务动作、边界和抓手，不写厂商、版本、菜单。

一篇是否收录，依次问：

1. 站在上面的信条上吗？ 结论若是「组织目标没问清就套方法」「越先进越好」「一次性把台账整体搞好」「管资产管设备同一套」「上系统等于管了资产」，不收。
2. 是业务的方法与道理吗？ 是则收。源材料若混着产品操作（实施手册常如此），只萃取业务逻辑，「点哪个按钮」留在门外。
3. 对宣言里的读者有用吗？ 从资产管理出发用不上的，不收。作业安全、两票、物联测点，只要是管资产或维保时会碰到的接口，照收，并写清角色。
4. 能讲成一个概念吗？ 能，写成笔记；不能拆清，先当种子，注明缺什么。
5. 敢公开吗？ 能脱敏、不推销、引用有出处，才进外网。种子可以出处较弱，但必须标明是种子，并写清下一步补什么。

边界地带照收，但写明角色。 生命周期里不少环节不由资产管理部门主导（投资在规划部，转固在项目部和财务，采购在供应链）。它们决定日后接手的是什么，所以照收——必须写清谁主导、资产管理者的接口在哪。没有独立资产管理部门时，写清这件事通常落在哪个职能，不要假装有一个「资产部」在闭环。

不要抄进公开 Wiki： 公司作业规范、客户与项目材料、官网博客、网络热帖和短视频里的跟风说法（包括套模型生成的空话）。不要写客户名和内部作业。

二、长成什么样，入口怎么守

三层：导览/ 按课题铺路，三条路同一视角；笔记/ 扁平，一篇一概念，是主体；专题参考是未来的事，由笔记聚合，不替代笔记。现在不要新建 专题/ 或长文合集；果实是一篇笔记的成熟度，不是另一种体裁。

层次就是三条路 + 主题簇。主题簇只活在 index.md 上，不是文件夹。

现在只保留：index.md、花园宣言、导览/（三条路）、笔记/、本页。不要 README.md（发布器会当目录首页，链接 404）。不要 网络思维.md。

index.md 与三条导览各不超过 128 行。 行数按文件总行数算，含 frontmatter 与空行。入口浅，深度长在笔记之间的链接里。新词条要进来，先腾位置。

新笔记默认不上入口、不上导览。 写完先靠双链到达。挂上 index.md 或某条导览，是另一次决定，必须在 MR 里说明理由。不要因为「这篇写得好」或「同簇已经挂了邻居」就挂上。

上 index.md 主题簇，必须同时满足：是该簇读者会先打开的那一篇（总概念，不是专项）；标题罩得住整簇（即下文收编一节的标题重评）；腾得出行数。压不出位置，说明还不够格上入口，笔记本身仍保留。

上导览，必须同时满足：该节里读者不点这篇会走错或漏掉一个分界；该导览仍 ≤128 行。导览按课题选篇，index 按簇挂总概念，两边允许不一致。专项可以只从母篇点进去，也可以只出现在导览。

导览是带判断的索引，不是讲义：开篇可以有一段认路（形态、分岔），控制在约 20 行；每节至多两三句点出取舍或分界，链接自己说话。导览不讲新概念。笔记和导览正文不要写入口收编用的编辑用语（收编、腾位置、总概念、专项从母篇点进去）；index.md 可以用一句说明怎么走。

三条路怎么认，以各路开篇为准，不要互相套：

• 导览/资产管理者之路：先摊开职能形态，再按课题索引。在岗的人对照着走，正在划责或推动变革的人当核对表用。
• 导览/设备维保之路：运维方法相近，但对内与对外的管理诉求不同。用落地语言写清差异（如：修自己的设备算成本和完好率，对外做服务看合同计价和 SLA），不要用「账本分岔」等抽象对仗。写清操作与专业维修的分工。
• 导览/数字化建设者之路：先问三件事再进模块。仍从资产管理出发，不是产品选型指南。

腾位置用收编：同簇、且是同一个概念的几篇，入口只挂总概念那篇，专项从那篇点进去。笔记不删、不降级。

收编后必须重评入口上那篇的标题——这个词会被读成「这一簇」：

• 标题仍罩住本篇，其余只是下游或专项 → 收编成立，标题不动。
• 标题罩不住，正文得加一截新内涵才能讲圆 → 不是收编，是两个话题。 两边都重要，就都留在入口，互链，不塞进一篇。
• 不要把专项写进总概念篇来撑大，也不要改总概念标题去吞专项。

第一版的例子：资产经营 与 闲置低效资产盘活 相邻但不是同一话题，两篇都进入口。拿不准是不是同一概念，按两个话题处理，不要收编。

远景只记住三句：笔记可以很多，首页一直浅；任意相邻概念三次点击可达（这是远景，不作为每篇验收）；同一篇出现在多条导览上。权威性靠果实交叉印证标准与现场，不靠入口变长。

三、园内怎么互链

园内只用 Obsidian 双链，以能命中现有文件名为准：

• 笔记：[[什么是资产]]
• 导览：[[导览/资产管理者之路]]
• 显示文字与文件名不同时：[[投资规划的两种模式|投资规划模式]]
• 成熟度等后缀放在双链外面：[[资产合规与穿透式监管]]（种子）

首页是唯一的例外，不要写 [[index]]：index.md 被发布器映射为站点根，双链在公开站 404。提到首页时写 index.md（给园丁看）或完整 URL（给读者看）。

禁止相对路径（公开站会收成不可点纯文本，图谱也认不出邻居）：

[什么是资产](../笔记/什么是资产.md)

真正的站外 URL 仍用 Markdown，例如 无边界技术。

四、往哪长

读者的路走出来，再铺。没人走的路不预铺。当前优先（缺哪补哪，对照上面的信条）：

1. 合规与穿透式监管——信条第 9 条，现在几乎还是种子。向国资监管、行政事业、上市公司内控、特种设备法规展开。同根的是闲置低效资产及物资盘活，从 闲置低效资产盘活、资产经营 向公物仓、呆滞物资、不动产盘活生长。
2. 工业物联——三件事里最薄，信条未单列；写的时候对照第 4 条（分重点）和第 10 条（系统帮找抓手）。从业务侧写：测点、数据质量、报警到工单、边缘与平台分工；仍然不写产品。新写「采集链、边缘与平台」时用 主题/工业物联；已有的测点 / CBM 笔记可以继续用信息系统 / 维修维保。
3. 维保的手艺与生意——信条第 2 条（管设备相对标准化）；持续改善见第 4 条。诊断、工艺、班组、师徒；也包括服务提供方（制造商售后、ASC、集团运维公司），起点 面向客户的维保服务。
4. 行业专篇——通用道理讲完后按行业分蘖，用 行业/ 标签，成熟再聚合导览。不要一上来就按行业复制一套通用笔记。
5. 案例与数字——脱敏案例、行业基准值。数字比形容词可信。

某方向积累 5 篇以上，考虑在 index 单开簇、在导览加节——仍受 128 行和收编约束，不是自动上入口。

五、笔记怎么写

先看这篇站在哪条信条上；写出来的结论不要和信条对着干。

哪些文件不是「一篇一概念」

按笔记规范写的，只包括 笔记/ 里的概念篇。下面这几类例外，不要用笔记骨架去套：

• index.md、花园宣言、本页：元文件，不标成熟度。
• 导览/：索引，成熟度用幼苗即可，不靠导览当果实。
• 术语速查：对照表，不是定义篇。新词只在对应笔记成篇之后才进表。「成篇」指至少到幼苗；种子不进表。

文件名

文件名即标题，简单直白，便于搜索和链接。不用顿号以外的特殊符号、不用 emoji、不用序号前缀。已通行的缩写可以放进文件名（RCM、SAMP、EAM、MRO），不要把英文全称放进文件名。

中文表达

正文尽可能用中文。英文只留给三种必要：通行缩写（EAM、RCM、SAMP、CAPEX、OPEX），标准号与条款，以及中文会歧义、或行业里就靠这个词才认的术语。不要把英文定义整句括在中文后面，也不要为了对照原文把 very general、from assets 这类词嵌进正文。人名、地名、事故名、标准名保留原文。缩写在本篇第一次出现时用中文带出，例如 战略资产管理计划（SAMP）；不要假定读者刚看过术语速查。

一篇一概念，大了就拆

一篇只讲一个概念：读者是冲着标题里那一个问题来的。3–5 分钟读完。正文（不含 frontmatter 和「相关笔记」）以 400–1200 字为舒适区。

出现下面任一情况就拆：

• 出现第二个能单独当文件名的概念，且它需要自己的「适用与局限」；
• 正文超过约 1500 字，且多出来的部分能独立成篇。

拆之前仍要查重：已有则改，不另起同概念篇。拆出去的专项不自动进入口，从母篇点进去。不要在总概念篇里加一截新内涵来撑大。

不要拆： 对比表的两侧、同一概念的适用条件、必须放在一起才不歧义的一对词（如 EAM与CMMS、资产与设备的语境差异）。超过 1500 字但不拆的，在 MR 里写明为什么。拿不准拆不拆，拆。

frontmatter

---
tags: [主题/资产管理, 环节/运维, 行业/通用, 规模/通用]
maturity: 幼苗
source: 依据《某来源》某章整理
updated: 2026-08-30
---

四维必要，种子也不免。每维至少一个。主题在接口篇可以打两个（例如移交同时涉及投资规划与财务合规），第三个不要；环节、行业、规模默认各一个，不要把「通用」和更窄的取值打在一起。

词表不够用时先在本表加一行，再用，避免同义分叉（曾同时出现「环节/规划」与「环节/前期规划」）。未登记的取值不准用。

维度	现行取值	怎么选
主题	资产管理 · 投资规划 · 资产经营 · 维修维保 · 备件MRO · 财务合规 · 信息系统 · 工业物联	本篇主问题落在哪一簇就打哪个；接口篇可再加一个
环节	规划 · 购置 · 运行 · 维护 · 退出 · 整体合规	打读者主要在哪个阶段用它。跨阶段接口打变化发生的那一环（移交打购置，报废打退出），不要打「全生命周期」。「合规」只给本身就是合规动作的篇（法定检验、监管报告、减值测试），不给「顺带涉及合规」的篇
行业	见下方「行业词表」	例子可以来自某行业；只有道理本身绑死某行业才打该行业。拿不准打通用
规模	通用 · 中大型 · 大型	判定标准见下方「规模怎么判」。不要发明「中型」「中小」

行业词表

按「管理讲究是否不同」划分，不按国民经济行业分类死抠。登记齐本花园会写到的行业，未登记的仍要先加行再用：

取值	覆盖
通用	道理不绑死任何行业
流程制造	化工、冶金、建材、造纸、食品饮料等连续 / 批次生产
离散制造	机械、电子、汽车及零部件等装配型生产
石油石化	油气勘探开发、炼化、管输（比流程制造更窄，绑死油气讲究时优先打它）
电力能源	发电、电网、新能源场站
矿山	采掘、选矿
交通	公路、铁路、轨道交通、港航、机场
市政公用	水务、燃气、热力、环卫
建筑与地产	施工装备、物业持有与运营
医疗	医院与医疗设备管理
行政事业	机关、事业单位的国有资产管理

两条选择规则：道理绑死更窄的取值就打更窄的（炼厂的讲究打石油石化，不打流程制造）；一篇最多一个行业，横跨多个行业还成立的，说明是通用。

规模怎么判

打的是本篇方法成立所需的最小组织形态，不是读者企业的大小，也不按营收、人数、资产总额这类统计口径。从大往小问：

取值	判据	典型特征	例
大型	只有站在集团总部 / 多法人并表的视角才成立	跨法人、并表、穿透式监管、总部资产经营	跨法人资产调拨
中大型	不需要总部视角，但依赖多厂区、多法人或集团级职能之一（统一归口、共享服务、集中采购）	多厂协同、集团制度、共享库存网络	战略资产管理计划SAMP、MRO库存治理
通用	单法人、单厂区就能落地	一个车间也用得上	工单、预防性维护

不要因为「大企业更常做」就升档：工单在集团里也天天用，仍是通用。

source 是一条字符串，多个来源用顿号或分号排在同一行。现场反馈写「某类现场口头 / 复盘，已脱敏」，不要写企业名。种子的 source 可以较弱甚至暂缺，缺的写进「还缺什么」；幼苗起必须有来源。

updated 记最后一次实质修改：改了结论、来源、成熟度或相关笔记就更新；只修错别字、调链接不动它。

成熟度（作业标准）

宣言里是比喻，判定以本表为准。作者不能只凭「写得完整」自行标成果实。

级	这篇已经怎样	还缺什么时不要标这一级
种子	问题、目录或线索已经钉住；写清缺什么、下一步补什么；相关笔记至少 2 条	已经能当一个概念讲清，却标种子——该升幼苗
幼苗	一篇一概念已经讲清；至少一个来源；有「适用与局限」和「相关笔记」3–6 条	还没想清主问题，或缺适用与局限，却标幼苗——该留种子
果实	幼苗条件 + 至少两个彼此独立的来源（或一个来源 + 可核对的现场反馈）	只有同一本书的两章、同一本培训手册的两节，却标果实

独立来源 = 不是同一本书的两章、不是同一本培训手册的两节、不是同一作者换个标题。交叉印证的是说法，不是重复引用。

新笔记的初始成熟度由作者按本表自评，随首个 MR 一并复核，不为初始标级单独走升降。此后晋升：作者在 MR 里写明证据（两个来源分别是什么，或现场反馈是哪类），合入后才改 maturity。降级同样走 MR：果实有错先改，来源不够或关键结论被推翻则降为幼苗——降级不丢人，错着不改才丢人。

既有果实下次改这篇时核对 source；不够就补来源或降级，不搞一次性追溯运动。

种子可以没有完整的「适用与局限」，但必须有一节写清还缺什么（像 资产组 那样）。幼苗和果实必备「适用与局限」。

正文骨架

开头说清这是什么、为什么值得管（主导者不是资产管理部门时，第一段就写角色与接口）；中间讲道理、给例子和数字，对比用短表，流程用 mermaid，不用外链图床；必备「适用与局限」（中立与诚实的落点）；「相关笔记」幼苗和果实 3–6 条，种子至少 2 条。孤立的笔记等于没种。

相关笔记怎么算上下游： 上游 = 要先懂的概念（定义、前提）；下游 = 读完本篇会接着用的做法或专项。各至少一条。不要把同簇清单整组贴进来；只链读这篇时真会接着打开的。

文风：短句，先结论；假定读者懂行，通行概念不定义、不铺垫；用「常见做法是」，除非引的是法规硬性要求；坑和砸过的事一样有价值；不出现产品名与厂商倾向，来源写在 source。

去模板感

这里写的是业务笔记。不要情绪钩子、不要二人称煽情、不要悬念标题。笔记不是小说：开头不要主题宣言，不要靠钩子或把情绪写成身体反应来抓人。上面「文风」管口吻；这里管剥掉套模型的壳。事实、数字、标准名、责任主体要留；专业词要留。不要为了像人写的，把笔记写成口语帖。

• 少空副词。 「真正、非常、显著、完全、极其」能删就删。
• 删开场套话和空收尾。 「值得注意的是、综上所述、归根结底、本质上、简单来说、让我们来看」整句拿掉。
• 少用「不是 X，而是 Y」。 能直接说 Y 就说 Y。
• 段落不必同样厚。 不要每段观点 + 解释 + 收束。允许短段。能停在例子或后果上，就不要再概括一句。
• 无源不写「研究表明 / 数据显示」。 有公开出处用 Markdown 外链；没有就删整句，不要补假来源。
• 关键词该重复就重复。 不要为躲重复轮换同义词。
• 名词化还原成动作。 「对流程进行优化」写成「改流程」。公文固定说法和标准术语除外。
• 开头落到问题或定义。 第一段说这是什么、卡在哪；不要先喊主题。
• 该判断就判断。 需要站队时给出判断和适用边界，不要全程「可能 / 或许 / 一般来说」。
• 数字带适用条件。 写清谁、什么形态、什么口径；光甩一个数等于没写。
• 允许一条真实弯路。 和上文「坑」是同一类东西：走过、无效、为什么无效。不要编。
• 删无信息量的填充。 不要 chatbot 口吻（「好的，下面为您梳理」之类）。
• 不要一次上满。 骨架不要每篇盖章一样齐；上面这些规则每篇挑几条就够，留白。

提醒与技巧

和直觉、口头习惯或源材料打架、不看会做错的口径，用提醒。可复用、但不是硬性要求的做法，用技巧。两者都是短标注块，不是新的一节。

园内只用 Obsidian 标注块，类型名是语法、标题用中文。只准这两种，不要再发明「注意」「提示」「重要」：

> [!warning] 提醒
> 预转固虽然按暂估金额入账，通常并不会生成暂估科目。财务按正常的固定资产科目做账，只是流程叫「预转固」或「暂估转固」。

> [!tip] 技巧
> 总包设备即使直发现场，也先虚拟入库再按清单领出，成本和实物才对得上。

块	类型名	什么时候用	什么时候不用
提醒	warning	读者会按错的口径：词同义不同、流程名被听成科目、和源材料斜杠焊法打架	普通定义、对比表、适用与局限整节
技巧	tip	别人做成过的做法，拿去可以省事，不做也不违法	法规硬性要求、必须走的闭环（那些写进正文）

[!warning] / [!tip] 是标注块的类型名，不算把英文嵌进正文；标题必须写「提醒」或「技巧」，不要改成同义词，也不要写成 [!提醒]——公开站和图谱只认这两套类型名。

块内一两句到一小段。一篇里每种各不超过约 2 个；处处高亮等于没高亮。不要把整节塞进块里，也不要用 emoji、HTML、:::warning 这类第二套语法。

六、每天怎么干

1. 读源料，找概念：一份材料通常拆 1–5 个概念，别整篇搬运。写的时候若一篇已经装了两个能单独命名的概念，继续拆。
2. 先查重：搜 笔记/ 和 术语速查。已有则补充或晋升，不另起炉灶。
3. 按规范写：对照信条、骨架、frontmatter、词表、成熟度、中文表达。
4. 织网：新笔记连旧笔记，再回到 1–3 篇旧笔记补反向链接。只出不进长不成网络。
5. 登记：对应主题簇；新术语在成篇之后进术语速查。默认不改 index、不改导览。 若这次要上入口或收编，先看入口行数，按第二节做，并在 MR 里单独说。
6. 自查：用第七节清单过一遍。
7. 成簇后铺路：某方向积累 5 篇以上，考虑在 index 单开簇、在导览加节——仍是一次入口决策，不是写完第 5 篇就自动挂。

七、合入与修剪

质量不靠自觉，靠出门时过这张清单。允许各写各的，只有例子、句式、相关笔记在 3–6 条里怎么选。成熟度、拆不拆、标签、上不上入口、收不收产品，不按个人习惯。

谁拍板

事项	谁决定
在已有词表内打标签、织网、改幼苗正文（不改结论方向）、给种子补厚	作者直接做
升 / 降成熟度、改 index.md 或导览、新增标签取值、合并或移走笔记、超过 1500 字不拆	MR 里写明理由，合入者同意后再生效

合入者按下面清单复核。当时没有第二人，作者切换角色，隔开至少半天再当合入者勾一遍，不要写完立刻合。

合入清单

作者勾、合入者复核：

• 信条：结论没有对着干；形态 / 对内对外 / 接口该写的写了
• 一篇一概念；超约 1500 字已说明为什么不拆
• frontmatter：四维均在词表内；maturity 与 source 匹配（果实能看出两个独立来源）
• 骨架：幼苗和果实有「适用与局限」，相关笔记 3–6 条，上下游各至少一条；种子相关笔记至少 2 条，写清还缺什么
• 双链可达；无相对路径、无图床、无产品名与厂商倾向、案例已脱敏
• 中文表达：没有把英文整句嵌进中文；缩写在本篇第一次用中文带出；扫一遍套话、空副词、「不是而是」密度；该判断的地方有判断，数字有适用条件，没有 chatbot 口吻
• 提醒 / 技巧：只用本手册规定的两种标注块；标题是「提醒」或「技巧」；没有第三种，没有把整节塞进块里
• 默认未改 index / 导览；改了则说明收编或行数，且仍 ≤128 行
• 新标签取值已先改本手册词表
• 新术语已在对应笔记成篇后进入 术语速查
• 公开笔记未夹带审阅正文；审阅材料只在 _reviews/

WIKI 正文改在工作区；由 Editor_Wiki 开 feature 分支 + MR 自合进 main（只动 业务知识/WIKI/）。不要在 nethot 等其他业务分支上改 WIKI，也不要两人同时改同一篇。合入清单仍用。

站内审阅与私有反馈

公开笔记（笔记/、导览、index.md、花园宣言.md、手册正文）不含审阅正文、批注串、员工吐槽原文。

• 私有审阅落在 业务知识/WIKI/_reviews/；与公开站平台 REVIEWS_DIR 同构（平台侧由 Dev_Wiki 配置，本手册只定内容约定）。
• _reviews/ 不进公开 https://www.digiinfr.com/kb/ 的页面构建与导航；读者在站上看不到审阅目录。
• 队列状态：open = 待处理；done = 已处理。标 done 时写 1–2 句 resolution（改了什么 / 为何不改），回执写回原评论；待办列表不再显示该条。
• 谁改正文：Editor 经平台下载审阅 MD，人工辩证核实后改公开笔记，再走 feature + MR 自合，然后喊 BT_Deploy 挂 /kb。禁止程序自动改正文；平台 API 由 Dev_Wiki 做，本手册不规定接口细节。
• 闭环：挂站 /kb → 员工站内留审阅（入队 open）→ Editor 下载处理 → 改公开笔记并合入 → 回执 done + resolution → 再挂 /kb（若有正文变更）。
• 已弃用：用 GitLab Issue + wiki-feedback（或同类）标签收反馈的路径已弃用；新反馈走站内审阅，不新开这类 Issue 当主渠道。

每月修剪

当月合入过笔记的人做一次（不止一人则轮流：上月做过的这次不做）。结果用一句记在本页修订记录，或记在当次 MR。

• 校验链接与 frontmatter
• 入口是否仍 ≤128 行
• 标签有无同义分叉、有无未登记取值
• updated 超过一年的果实复核
• 重复的合并（保留更能当总概念的标题，另一篇改成指向它的短页或删前先搜谁链到它）
• 离题的从入口和导览摘掉；正文首段标明已移出主路、待改或待删。删除必须在 MR 里列出谁链到它