技术中文写作规范

技术文章像一位熟悉问题的工程师向另一位工程师解释：先把现象和数据说清楚，再沿原因、机制与实现推进。读者应当知道每一步发生了什么，为什么成立，如何验证。

用因果推进解释

先说具体对象和动作。例如“顶点沿法线移动”“Render Graph 删除没有消费者的通道”“GPU完成后回收上传区间”。主语明确，读者才能追踪数据和执行者。

一个有用的解释顺序是“现象 → 原因 → 机制 → 实现 → 结果 → 失效与代价”。它用于组织推理，正文根据实际依赖调整顺序。同一篇文章的章节应沿一条问题线前进。

硬边处会出现裂缝，因为同一个位置通常存在多个法线不同的顶点。沿各自法线外扩后，这些顶点会向不同方向移动，于是原本相连的轮廓被拉开。

这段话交代了现象、输入差异、动作和结果。随后自然进入“怎样让这些顶点沿同一个方向移动”。读者已有解决问题的动机。

句子与段落

短句交代动作，中等长度的句子解释条件和因果。一个句子承担一个主要关系；多个前提分别写清，再给结论。公式前定义变量、单位和空间，公式后解释变量变化带来的结果。

一段围绕一个子问题展开。段落开头直接写机制或观察，后面的句子提供原因、细节和限制。通用介绍、重复上一段的总结和没有新信息的转折可以直接删去。

自然的技术叙述给推理留出空间。句子长短服务于解释：遇到一个问题，说明为什么出现，再引出所需的数据或操作。完整讲清一条关系往往需要几句话，篇幅由读者理解这条关系的需要决定。

叙述也要有轻重。影响方案选择、容易出错的机制展开讲，普通输入条件在代码前集中交代，补充限制放到对应问题出现的地方。复读关注读者是否能跟上整条推理，不要求每段都重复前提、机制、例外和验证。

“通常”“可能”“取决于”应接具体条件。例如“异步计算可能降低帧时间，前提是图形路径仍有空闲执行资源，新增等待没有进入关键路径”。不确定结论保留范围，事实核验负责补证据。

自然过渡

过渡指出尚未解决的问题，以及下一步要改变的数据或状态：

“壳已经扩张，但硬边仍然裂开。先检查同位置顶点的外扩方向。”
“法线连续后，再决定线宽使用模型单位还是像素单位。”
“固定像素宽度让远处小物体的轮廓显得过重，可用距离和轮廓重要性限制宽度。”
“深度图只能表示最近表面。要给被遮挡的选中对象描边，还需要单独的对象遮罩。”

每句过渡都推动技术问题。全篇无需反复使用“接下来我们将介绍”“我们可以看到”“需要注意的是”。

写成定稿

正文陈述现行规则、机制和成立条件。协作过程与相对旧稿的改动写入更新记录或迁移说明。技术限制写成明确条件，例如“该示例使用静态闭合网格，透明与蒙皮场景见相应扩展”。

来源正例

以下短句来自用户指定参考文章《风格化渲染常用技巧总结：描边》，作者别看着我笑了，原文：知乎603649633。它们用于说明表达方式；技术断言按规范、版本与实验独立核验。

实现原理：用一张RenderTexture单独绘制纯色网格（Command Buffer），然后对这张RenderTexture做模糊操作，减去模糊前的得到描边，再与原本的渲染结果混合。

有价值的写法是连续追踪输入、中间结果和合成。正式正文需要明确相减方向：用模糊遮罩减去原遮罩，再截取正值，得到物体外侧的软边。硬轮廓可用膨胀遮罩减原遮罩。

传统的做法是在第一个Pass的顶点着色器中将顶点沿法线向外偏移，并绘制描边的颜色，然后在第二个Pass中绘制原本效果。

这句话直接说明绘制顺序和覆盖关系。落地文章还要交代剔除、深度和写入状态，因为执行顺序本身不能保证正确遮挡。

沿法线外扩的通病就是由于在拐角或锋利的边缘处的顶点法线不连续。

现象解释紧贴数据差异。正文继续说明同位置多顶点、方向分歧和焊接策略，推理链就完整了。

项目文章正例

以下段落来自描边，表达从具体原因出发，再处理第一种修法带来的问题：

既然裂缝来自方向不一致，让接缝上的顶点沿同一个方向移动就能把它们重新接起来。但着色法线之所以分开，正是为了保留硬边的光照。直接平滑这份法线，轮廓可能连续了，原来的棱角明暗却也会改变。

后续解释因此有了依据：独立的描边方向负责连续外扩，原着色法线负责硬边光照。有效过渡把已经解决的问题和剩余问题接起来：

到这里，壳的方向已经有了，但对象空间宽度还会随距离变细。如果目标是让线条始终占几个像素，就从屏幕位移反推裁剪坐标中的偏移。

跨主题文章沿自己的技术依赖推进。Render Graph 可以从一个效果的生产与消费关系讲到同步、剔除和资源寿命，不需要重复描边的句式或章节。

正文写法示例

写作任务	可采用的句子	表达作用
数据流	把对象渲染为二值遮罩，膨胀遮罩，再减去原遮罩，剩下的像素就是外侧轮廓。	数据、操作和结果明确
变量关系	当表面转向侧面时，法线与视线的点积趋近零，可以用这个值控制表面边缘的色带。	变量变化与用途相连；限制另段说明
失效诊断	镜像UV让切线基底手性改变。解码平滑方向时漏乘切线的符号，接缝两侧就会向不同方向外扩。	症状能追溯到一个输入约定
工程边界	这个法线缓冲保存着色法线，所以法线贴图的细节也会触发轮廓。需要结构线时，改用几何法线或对象ID。	问题、原因和修法具体

写作复读

每篇文章分别检查这些问题：

首段是否直接给出技术问题和输入，后续解释是否沿同一问题推进？
动作的执行者、数据和结果是否明确？
结论前是否给出支撑机制，性能和质量判断是否有条件？
每段是否增加信息，术语是否定义后统一使用？
过渡是否指出真实缺口，长句是否可拆为更清楚的依赖？
删除通用介绍和机械总结后，因果链是否仍完整？
修辞、口语与比喻是否帮助理解？技术正文使用自然表达，保留准确术语和必要限制。

复读时再做三项具体检查：

看到“需要”“可以”“应”或“这样做会”，追问理由。机制解释段在本段或相邻段回答原因，命令、图注和数据定义保留各自的用途。
连续出现空间、格式、蒙皮、矩阵等名词时，跟踪它们之间的动作与因果。必要时把名词句展开为“哪份数据发生了什么变化，为什么引出下一步”。
每个机制大章节都有实际问题推动的过渡，指出当前方案已解决什么、还留下什么问题。连接词按这个关系使用，作者可以自然说明“我们先处理这个问题，再看另一条路径”。

写作状态为“通过、需重写、待复读”。扫描命中只生成候选，词频和句长不自动决定质量。全库P0语言复读覆盖每一篇文章，边界保持的文章同样记录结果。