findscripter 何时使用
当被要求撰写公司内部的沟通文书时使用，覆盖以下类型：
- 3P 进展报（Progress / Plans / Problems 进展、计划、问题）
- 全员通讯（company newsletter，全公司可读的周报/月报）
- FAQ（汇总并回答全公司高频问题）
- 状态报告、领导汇报、项目更新、事故报告等
不该用的边界：对外新闻稿与公关文案、面向客户的营销内容、SEO 长文（用 seo-content-writer）、代码与 API 文档、个人简历。这些都不是「内部沟通」。
核心原则：先判定文书类型，再套用该类型对应的固定格式；内容力求简洁、数据驱动、要点前置。
步骤
- 识别类型：从需求判定属于 3P / newsletter / FAQ / 其他通用四类中的哪一种；无法归类时，向用户追问目标受众、目的、语气与格式要求。
- 澄清范围：确认团队名 / 公司名与时间范围（Progress、Problems 取「过去一周」，Plans 取「未来一周」）。团队名缺失时直接询问。
- 收集信息：尽量从可用来源拉取素材——
- Slack：大频道里高互动（多回复/多 reaction）的帖子
- 邮件：高管发出的全公司公告、长内容或多回复邮件
- 文档（如 Google Drive）：高浏览量的关键文档、季度规划、愿景文档
- 日历：All-Hands、产品评审等大型非例行会议及其附件文档
- 外部报道：近期媒体引用或获得的报道 若无相关工具权限，直接请用户提供要点；此时你主要负责套格式润色，并可提示「接入这些来源后产出会更好」。
- 按固定格式起草：见下方各类型格式，格式必须严格遵守。
- 复核：3P 控制在 30-60 秒可读完；尽量带指标；语气就事论事，少用华丽长句。
指令
3P 进展报（受众：高管/领导/同事，对团队有一定但不深的了解；篇幅极短） 固定格式，除此之外不要使用其他格式；emoji 选一个能体现团队与本期氛围的：
[emoji] [团队名]（覆盖日期，通常一周）
Progress：[1-3 句，已交付/达成的里程碑/已完成任务，尽量带指标]
Plans：[1-3 句，下周最高优先级、最受关注的事]
Problems：[1-3 句，拖慢团队的阻塞、缺人、bug、谈崩的合作等]
团队越大，任务粒度越粗（如「移动团队：上线了某功能」对比「公司：新招 20 人、签下 10 个新单」）。
全员通讯 newsletter（受众：1000+ 人全公司；经 Slack + 邮件发送） 约 20-25 条 bullet，每条 1-2 句；多放链接（关联文档、公告频道高管帖、全员邮件）；用「我们（we）」口吻。按主题分组成节，让公司各板块都被覆盖，例如 {产品研发 / GTM / 财务} 或 {招聘 / 执行 / 愿景} 或 {内部新闻 / 外部新闻}。
:megaphone: 公司公告
- ...
:dart: 重点进展
- 板块一
- 子项
- 板块二
- 子项
:pillar: 领导动态
- ...
:thread: 社区/社交动态
- ...
优先：全公司影响、领导公告、重大里程碑、影响多数员工的信息、外部认可/报道。避免：过细的单团队更新（留给 3P）、仅小群体相关的信息、已传达过的重复内容。
FAQ（汇总全公司高频困惑并简答） 格式：
- *问题*：[1 句]
- *回答*：[1-2 句]
要holistic：覆盖整个公司而非提问者本人或其团队。答案尽量基于官方沟通；信息不确定时明确标注；链接到权威来源；语气专业而亲和；需要高管定夺或官方回应的问题要标记出来。常见主题：融资、新高管、即将发布的产品、招聘进展、愿景/重点变化等。
通用内部沟通（不属上述三类时） 先问清：目标受众、沟通目的、期望语气（正式/随意/紧急/告知）、格式要求。原则：清晰简洁、用主动语态、最重要信息前置、附相关链接、贴合公司沟通风格。
示例
3P 进展报：
🚀 移动团队（5/26 - 6/1）
Progress：上线了 v2.3 登录改版，崩溃率下降 18%；关闭 24 个积压 bug。
Plans：开始离线模式预研，目标本周出技术方案；配合营销完成 6/8 发布演练。
Problems：缺 1 名 iOS 工程师，影响排期约 1 周；与支付方联调被对方 API 限流阻塞。
FAQ：
- *问题*：B 轮融资什么时候完成，对期权有何影响？
- *回答*：已于上周完成，公告见 #announce 频道帖子；期权细则将由财务在全员邮件中单独说明（需 HR/财务官方确认）。
注意事项
- 格式是硬约束：3P 与 newsletter 的版式不要自由发挥。
- 简洁优先：3P 每节 1-3 句、就事论事；newsletter 每条 1-2 句。
- 数据驱动：能给指标就给指标，避免空泛形容。
- 缺信息就问：团队名、时间范围、受众等关键信息缺失时主动澄清，不要臆造。
- 来源真实：FAQ/通讯里引用的事实应来自官方沟通；不确定要标注，必要时标记需高管定夺。
- 本技能改写自 Apache-2.0 / 许可源（原 internal-comms），保留其格式与约束要点。
互见
- fact-checking：发布前核对通讯/FAQ 中引用的事实与数据。
- markdown-to-docx：需要把成稿导出为 Word 正式文档时。
- seo-content-writer：面向对外的内容写作（与本技能边界互补）。