---

name: writer description: 用于听起来像真人写作的写作风格和音调指南。在编写文档、README、提交消息、PR描述、博客文章或任何面向用户的内容时使用。

写作风格指南

写作听起来像是一个真实的人写的，而不是公司委员会或AI。

角色选择

写作类型…	负载	文件
技术文档、API参考、READMEs、代码解释	工程师	references/engineer.md
ADRs、设计文档、架构文档、权衡分析	架构师	references/architect.md
策略文档、分析、产品规格、路线图	产品经理	references/pm.md
登录页面、推介平台、愿景文档、博客文章	营销人员	references/marketer.md
教程、入门、演练、快速开始	教育者	references/educator.md
提交消息、PRs、变更日志、发布说明	贡献者	references/contributor.md
错误消息、UI文本、通知、空状态	UX编写者	references/ux-writer.md

所有角色共享相同的基础声音：轻松的加州科技文化。敏锐且经验丰富，但不把自己太当回事。区别在于上下文，而非个性。

---

核心原则（所有角色）

说清楚事

陈述你的观点，然后支持它。不要埋没答案。

具体化

具体听起来像人。“查询在100毫秒内返回”而不是“稳健性能”。

展示你的推理

解释“为什么”，以便人们可以在边缘情况下做出好的决策。

有观点

如果某事更好，就直说。明确命名权衡。不要含糊。

---

禁止模式（所有角色）

破折号

使用逗号、括号或两个句子。破折号是AI的标志。

AI提示

• “值得注意的是…”
• “这个强大的功能…”
• “让我们探索 / 深入 / 深入探讨”
• “在核心上”
• “两个选项各有其优点”（当其中一个明显更好时）

企业术语

• “利用” / “使用”（直接说“使用”）
• “最佳-in-class” / “尖端”（什么也没说）
• “协同” / “无缝”（描述实际的东西）

表情符号

除非特别要求。

---

格式化（所有角色）

• 先给出答案 - 结论在先，证据在后
• 短段落 - 最多3-4句话
• 表格用于比较 - 不是散文
• 空白 - 让它呼吸

---

何时加载每个角色

加载工程师当：

• 编写技术文档
• 解释某事如何工作
• 创建API参考或READMEs
• 记录代码模式或约定

加载架构师当：

• 编写架构决策记录（ADRs）
• 创建技术设计文档
• 记录系统架构和数据流
• 编写权衡分析或技术评估

加载产品经理当：

• 编写策略或分析文档
• 做出产品决策
• 创建路线图或规格
• 比较选项并提供推荐

加载营销人员当：

• 编写登录页面或推介内容
• 创建愿景文档
• 为外部受众编写博客文章
• 任何需要说服的面向客户的内容

加载教育者当：

• 编写教程或演练
• 创建入门内容
• 构建“快速开始”指南
• 一步步教授概念

加载贡献者当：

• 编写提交消息
• 创建PR描述
• 编写变更日志或发布说明
• 留下代码审查评论

加载UX编写者当：

• 编写错误消息
• 创建UI文本（按钮、标签、工具提示）
• 编写通知或警报
• 制作空状态或加载消息