用 AI 帮忙写文档
把 AI 用在它靠得住的地方，并且知道哪些事它做不了。
概览
AI 能帮你把一段口头记录整理成条目、把生硬的句子改顺、把英文资料转成中文。这些事它做得又快又好。
它做不了的是为你负责。它会用完全自信的语气给出编造的事实、不存在的网址、看起来很像但其实错误的命令。文档一旦上线，读者会照着做，出错的代价由社团承担，不由 AI 承担。
所以本站对 AI 的态度是：用它起草，但每一条事实由你核实过才能提交。
可以交给它做的事
- 整理。把会议的零散记录、聊天里的结论，整理成分节的条目。
- 润色。你已经写好意思，让它把句子改通顺、去掉重复。
- 翻译。把英文官方文档的一段转成中文，作为你理解的辅助。
- 对照检查。把你写的和本站已有的页面一起给它，让它指出语域和格式上的不一致。
- 找出你没想到的情况。例如问它“这段命令在 Windows 上会怎样”，它给的答案要你自己验证，但它能提醒你有这么一档事。
不要交给它做的事
- 不要让它替你确定事实。 版本号、端口号、命令参数、日期、人名，都要你自己查。
- 不要让它生成参考链接。 它编出来的网址常常长得很像真的。本站每个外链都要点开确认过。
- 不要让它写归档内容。 归档记录的是真实发生过的事，缺什么就标出来缺什么，任何补全都是伪造史料。
- 不要整篇照抄它的输出。 它的中文有一套很好认的腔调：满篇“因此”“总之”“不难看出”，爱用破折号，爱说“非常重要”“极大提升”。这些词在本站正文里应当接近于零。
怎么核实它给的东西
命令：在自己机器上真的跑一遍。跑不了的（比如你没有 Windows），就找官方文档确认参数，或者在文中写清楚这一条未经实测。
事实与数字：找到一手出处。规范类的找 RFC 或标准组织，工具类的找官方手册，本仓库的情况直接看仓库里的文件。做法与各站的锚点写法见现有教程里的“延伸阅读”。
链接：每一条都点开。要批量检查，构建之后跑：
pnpm run ci:verify它会报告站内断链与失效锚点。站外链接要你自己点。
渲染结果：AI 写的 Markdown 可能在本站渲染不出预期效果。判断依据是构建产物，见 VitePress。
让它写出本站的样子
直接让 AI“写一篇技术文档”，出来的东西不会像本站。给它约束会好很多：
- 先让它读一两篇本站已有的同类页面，明确说“照这个语域写”；
- 告诉它引号用
“”，不要用「」； - 告诉它不要用破折号堆句子，不要写“因此”“总之”这类过渡词；
- 告诉它每个结论要附出处链接，链到具体条款而不是文档首页；
- 告诉它命令要给 macOS、Linux、Windows 三种写法。
写完之后你自己通读一遍。读起来像人话、每句都站得住，才算可以提交。
一段可以直接用的提示词
我要给 NBTCA 文档站写一页文档，主题是（……）。
先读这两页作为语域参考：
https://docs.nbtca.space/tutorial/terminal-shell-and-path
https://docs.nbtca.space/tutorial/manual/writing-documents
要求：
1. 中文正文，代码和命令用英文。引号用中文双引号，不要用直角引号。
2. 不要用破折号堆句子，不要写“因此”“总之”“不难看出”这类过渡词。
3. 每个结论附出处链接，链到具体的条款或章节，不要只链首页。
4. 命令给出 macOS、Linux、Windows 三种写法。
5. 你不确定的地方直接写“待核实”，不要猜，不要编链接。
写完列一张清单，说明哪些内容你没有把握、需要我去核实。最后那句很有用。它会逼着模型把不确定的部分显式列出来，而不是混在正文里蒙混过去。
归档的红线
归档不接受任何生成内容
archived/ 下的内容是社团的史料。规矩只有一条：没发生过的不写，不知道的标出来。让模型补全一段“看起来合理”的会议内容，等于伪造记录，比留着空缺严重得多。
规矩落到操作上：AI 可以帮你把已有的记录整理成条目、改通顺，但不能为你产生任何原本不存在的事实。
原件缺失的地方用 〔待核实：……〕 明确标注，渲染出来是一个带标签的待办标记，写法见 VitePress。留一个诚实的空缺，比填一段像模像样的猜测有价值得多。