diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml
new file mode 100644
index 0000000..70a2dee
--- /dev/null
+++ b/.github/workflows/validate.yml
@@ -0,0 +1,13 @@
+name: Validate Skills
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Validate skill packages
+        run: bash scripts/validate-skills.sh
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..ab826e7
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,50 @@
+# Contributing to ManageUp
+
+ManageUp is opinionated on purpose. Contributions should make workplace writing more concrete, more decision-ready, and less fluffy.
+
+## Skill package contract
+
+Each skill lives in `skills/<skill-name>/` and must include:
+
+- `SKILL.md`
+- `examples.md`
+
+Most `SKILL.md` files must contain these sections:
+
+- Frontmatter with `name` and `description`
+- `## 触发场景`
+- `## 必填输入`
+- `## 报告模板`
+- `## 反空话规则`
+- `## 质量检查`
+
+Exception:
+
+- `manage-up-core` is the methodology layer, so it may replace `## 报告模板` with methodology-specific sections such as workflow or framework guidance.
+
+`examples.md` must include:
+
+- At least one realistic user input
+- At least one ManageUp output
+- No invented facts beyond the provided input
+
+## Non-negotiable quality rules
+
+- Do not fabricate numbers, dates, names, business impact, or deadlines that the user did not provide.
+- If information is missing, leave it blank, mark it as `[待确认]`, or explain the uncertainty explicitly.
+- Prefer concrete evidence over polished wording.
+- Keep Chinese and English guidance aligned in structure and intent.
+
+## Before opening a PR
+
+1. Run `./scripts/validate-skills.sh`.
+2. Read your examples line by line and remove any unsupported claims.
+3. Check that your skill clearly inherits the ManageUp core principles.
+4. Make sure a new user can understand the skill without extra repo context.
+
+## What good contributions look like
+
+- A new report type with a clear business use case
+- Better examples that demonstrate anti-fluff writing without hallucination
+- Better validation, docs, or installation guidance
+- Smaller wording improvements that make prompts more precise and easier for agents to follow
diff --git a/README.md b/README.md
index 9c19894..bbf286f 100644
--- a/README.md
+++ b/README.md
@@ -124,6 +124,30 @@ ManageUp 不只是给工程师用的。所有需要写报告给老板的人都
 3. 必须包含反空话规则和质量检查清单
 4. 示例必须包含"空话版 vs ManageUp 版"的对比
 
+开始贡献前，建议先阅读 [CONTRIBUTING.md](CONTRIBUTING.md) 和 [docs/quality-roadmap.md](docs/quality-roadmap.md)，并运行：
+
+```bash
+./scripts/validate-skills.sh
+```
+
+详细规范见 [CONTRIBUTING.md](CONTRIBUTING.md)。
+
+## 质量保障
+
+仓库现在包含一套基础质量门禁：
+
+- `bash scripts/validate-skills.sh` 会检查每个 skill 是否包含必需文件和关键章节
+- GitHub Actions 会在 push / pull request 时自动运行校验
+- `manage-up-core` 现在也包含示例，便于理解方法论本身如何落地
+
+如果你准备新增 skill，建议先跑一次：
+
+```bash
+bash scripts/validate-skills.sh
+```
+
+如果你想先快速感受效果，再决定是否安装，先看 [docs/showcase.md](docs/showcase.md)。
+
 ## License
 
 MIT
diff --git a/docs/quality-roadmap.md b/docs/quality-roadmap.md
new file mode 100644
index 0000000..a0d975b
--- /dev/null
+++ b/docs/quality-roadmap.md
@@ -0,0 +1,57 @@
+# ManageUp Quality Roadmap
+
+## Why this exists
+
+ManageUp already has a clear point of view, but the repository still feels more like a prompt dump than a polished product. This roadmap defines the next quality bar:
+
+- The repo must be trustworthy: examples cannot invent facts the user did not provide.
+- The repo must be maintainable: every skill should follow the same package shape and section contract.
+- The repo must be usable: a new contributor should know how to add or improve a skill without guessing.
+- The repo must be demoable: the value of "anti-fluff" should be obvious within 2 minutes of landing on the repo.
+
+## Current gaps
+
+### P0: Trust
+
+- Some examples add metrics, dates, or business impact that were not present in the user's input.
+- `README.md` says every skill contains `examples.md`, but `manage-up-core` currently does not.
+
+### P1: Maintainability
+
+- There is no automated validation for skill completeness or required sections.
+- There is no contributor guide beyond four short bullets in the README.
+- There is no CI to stop incomplete or inconsistent skill packages from landing.
+
+### P2: Productization
+
+- The repo has good content, but little "show me" packaging: no quick showcase page, no quality rubric, no visible roadmap.
+- Installation and verification guidance exists, but there is no single "how to evaluate output quality" reference.
+
+## Execution plan
+
+### Phase 1: Fix trust and repo hygiene
+
+- Remove invented facts from examples.
+- Add `skills/manage-up-core/examples.md`.
+- Add a validator for required files and section headings.
+- Add CI to run the validator on every change.
+
+### Phase 2: Raise contributor quality
+
+- Add a proper `CONTRIBUTING.md`.
+- Define a standard skill package contract.
+- Require examples to clearly separate user input from generated output.
+
+### Phase 3: Make the repo feel exciting
+
+- Add a showcase doc with strong before/after transformations across roles.
+- Add a "quality rubric" doc that people can use even without installing the skills.
+- Add one or two new high-value skills that extend beyond classic status reports, such as upward email drafts or 1:1 prep.
+
+## Definition of done for a high-quality skill
+
+- `SKILL.md` exists and includes triggers, required inputs, templates, anti-fluff rules, and a quality checklist.
+- `examples.md` exists and does not invent facts outside the user input.
+- The skill works for both Chinese and English requests.
+- The examples show measurable improvement over vague baseline output.
+- The skill passes repository validation.
diff --git a/scripts/validate-skills.sh b/scripts/validate-skills.sh
new file mode 100755
index 0000000..ac75c1d
--- /dev/null
+++ b/scripts/validate-skills.sh
@@ -0,0 +1,60 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+repo_root="$(cd "$(dirname "$0")/.." && pwd)"
+skills_dir="$repo_root/skills"
+
+fail() {
+  echo "ERROR: $*" >&2
+  exit 1
+}
+
+[[ -d "$skills_dir" ]] || fail "missing skills directory"
+
+default_required_sections=(
+  "## 触发场景"
+  "## 必填输入"
+  "## 报告模板"
+  "## 反空话规则"
+  "## 质量检查"
+)
+
+core_required_sections=(
+  "## 五大原则"
+  "## 输入优先工作流"
+  "## 质量检查清单"
+)
+
+skill_count=0
+
+for skill_dir in "$skills_dir"/*; do
+  [[ -d "$skill_dir" ]] || continue
+  skill_count=$((skill_count + 1))
+
+  skill_md="$skill_dir/SKILL.md"
+  examples_md="$skill_dir/examples.md"
+
+  [[ -f "$skill_md" ]] || fail "$(basename "$skill_dir"): missing SKILL.md"
+  [[ -f "$examples_md" ]] || fail "$(basename "$skill_dir"): missing examples.md"
+
+  grep -q '^---$' "$skill_md" || fail "$(basename "$skill_dir"): missing frontmatter delimiter"
+  grep -q '^name:' "$skill_md" || fail "$(basename "$skill_dir"): missing frontmatter name"
+  grep -q '^description:' "$skill_md" || fail "$(basename "$skill_dir"): missing frontmatter description"
+
+  required_sections=("${default_required_sections[@]}")
+  if [[ "$(basename "$skill_dir")" == "manage-up-core" ]]; then
+    required_sections=("${core_required_sections[@]}")
+  fi
+
+  for section in "${required_sections[@]}"; do
+    grep -q "$section" "$skill_md" || fail "$(basename "$skill_dir"): missing section '$section'"
+  done
+
+  grep -q '### 用户输入\|### User Input' "$examples_md" || fail "$(basename "$skill_dir"): examples missing user input section"
+  grep -q '### ManageUp 输出\|### ManageUp Output\|### ManageUp 行为' "$examples_md" || fail "$(basename "$skill_dir"): examples missing ManageUp output section"
+done
+
+[[ "$skill_count" -gt 0 ]] || fail "no skills found"
+
+echo "Validated $skill_count skills successfully."
diff --git a/skills/manage-up-core/SKILL.md b/skills/manage-up-core/SKILL.md
index 172cfb7..122c25b 100644
--- a/skills/manage-up-core/SKILL.md
+++ b/skills/manage-up-core/SKILL.md
@@ -9,6 +9,14 @@ description: "ManageUp 核心方法论：将大模型的空洞报告改造为数
 
 ---
 
+## 触发场景
+
+- 用户要求写任何向上汇报类内容，例如周报、月报、项目汇报、绩效自评、提案、会议纪要、复盘
+- 用户只给了一个模糊请求，例如“帮我写个报告”“整理成老板能看的版本”
+- 其他 ManageUp 技能被触发时，本技能的五大原则默认一并生效
+
+---
+
 ## 五大原则
 
 所有 ManageUp 技能共享以下原则。生成任何报告前，逐条检查是否违反。
@@ -85,6 +93,24 @@ description: "ManageUp 核心方法论：将大模型的空洞报告改造为数
 
 ---
 
+## 必填输入 (Required Inputs)
+
+在通用场景下，如果用户没有提供足够事实，先一次性收集以下输入：
+
+```text
+为了写出一份数据驱动、可汇报的内容，请尽量提供：
+
+1. 你完成了什么：具体交付物、决策、里程碑
+2. 关键数据：数量、日期、比例、金额、时长、前后对比
+3. 风险或阻塞：卡在哪里、影响多大、需要谁帮助
+4. 下一步：接下来最重要的 2-3 件事和目标时间
+5. 是否需要老板决策：如果需要，请写明截止时间和不决策的后果
+
+没有的信息可以留空，我不会编造数据。
+```
+
+---
+
 ## 输入优先工作流 (Input-First Workflow)
 
 这是 ManageUp 最关键的设计：**先问，再写**。
@@ -161,6 +187,15 @@ ManageUp 同时支持中文和英文输出。
 
 ---
 
+## 反空话规则 (Anti-Fluff Rules)
+
+- 没有数据支撑的判断不要写
+- 优先把“进展顺利”“积极推进”“表现出色”改成数字、日期、交付物和影响
+- 如果一句话不能回答“所以呢”或“老板需要做什么”，就删掉或重写
+- 具体替换方式遵循上文“禁用词 → 替换表”和“校准语言”规则
+
+---
+
 ## 质量检查清单 (Quality Checklist)
 
 每份报告生成后，逐项验证：
diff --git a/skills/manage-up-core/examples.md b/skills/manage-up-core/examples.md
new file mode 100644
index 0000000..75f8ee4
--- /dev/null
+++ b/skills/manage-up-core/examples.md
@@ -0,0 +1,61 @@
+# ManageUp Core Examples
+
+## 示例一：信息不足时先补输入
+
+### 用户输入
+
+```text
+帮我写周报
+```
+
+### ManageUp 行为
+
+```text
+为了写出一份数据驱动的周报，请提供以下信息（可以用口语化的方式，我来帮你整理）：
+
+1. 本周完成的事：例如完成了哪些任务、交付了什么结果
+2. 关键数据/指标：例如 DAU、转化率、工单数、收入、完成率
+3. 风险或阻塞：例如被什么卡住、可能影响什么、需要谁帮助
+4. 下周计划：例如最重要的 2-3 件事和预计日期
+5. 需要老板关注的事（可选）：例如需要审批、协调、拍板
+
+没有的信息可以跳过，我不会编造数据。
+```
+
+### 为什么这符合 ManageUp
+
+- 没有拿着空输入硬写空话报告
+- 一次性收集关键事实，减少来回
+- 明确承诺不会编造数据
+
+---
+
+## Example 2: Same facts, different quality bar
+
+### User Input
+
+```text
+This week I finished the login refactor, fixed 8 bugs, and DAU went from 12,000 to 14,500.
+We are blocked on payment API docs from a third party.
+Next week I need to start push notifications.
+```
+
+### Weak Output
+
+```text
+This week the team made strong progress across multiple areas and continued to improve product quality.
+We also maintained close collaboration with external partners and will keep pushing key initiatives next week.
+```
+
+### ManageUp Output
+
+```text
+Bottom line: login refactor is complete, 8 bugs were fixed, and DAU increased from 12,000 to 14,500 (+20.8%). Main blocker: payment API docs are still missing from the third party, which may delay integration work next week.
+```
+
+### Why it is better
+
+- Starts with the conclusion
+- Uses only facts present in the input
+- Turns a vague blocker into an explicit risk
+- Gives the reader enough context to act
diff --git a/skills/meeting-summary/examples.md b/skills/meeting-summary/examples.md
index 795a348..a8eb726 100644
--- a/skills/meeting-summary/examples.md
+++ b/skills/meeting-summary/examples.md
@@ -23,9 +23,9 @@
 ```markdown
 # 会议纪要：v2.0 需求评审会
 
-**日期**：2026.03.19 | **时间**：14:00 - 15:00 | **方式**：线下
+**日期**：[待确认] | **时间**：[待确认] | **方式**：[待确认]
 
-**参会人**：老张（产品总监）、陈工（研发负责人）、小李（前端）、小王（设计）、Alice（QA）
+**参会人**：老张（产品总监）、我（研发负责人）、小李（前端）、小王（设计）、Alice（QA）
 
 ---
 
@@ -44,11 +44,11 @@ v2.0 首页改版确定采用方案 2（低风险迭代 + A/B Test），下周
 
 | # | 事项 | 负责人 | 截止日 | 状态 |
 |---|------|--------|--------|------|
-| 1 | 首页方案 2 设计稿终稿 | 小王 | 3/24（周一） | ⏳ 待完成 |
-| 2 | 反馈模块设计稿 | 小王 | 3/26（周三） | ⏳ 待完成 |
-| 3 | 首页性能排查——前端部分 | 小李 | 3/26 | ⏳ 待完成 |
-| 4 | 首页性能排查——后端部分 | 陈工 | 3/26 | ⏳ 待完成 |
-| 5 | 反馈模块前端开发（设计稿就绪后启动） | 小李 | 4/9（预计 1.5 周） | ⏳ 待设计稿 |
+| 1 | 首页方案 2 设计稿终稿 | 小王 | [待确认] | ⏳ 待完成 |
+| 2 | 反馈模块设计稿 | 小王 | 下周三前 | ⏳ 待完成 |
+| 3 | 首页性能排查——前端部分 | 小李 | [待确认] | ⏳ 待完成 |
+| 4 | 首页性能排查——后端部分 | 我 | [待确认] | ⏳ 待完成 |
+| 5 | 反馈模块前端开发（设计稿就绪后启动） | 小李 | 设计稿完成后约 1.5 周 | ⏳ 待设计稿 |
 
 ## 关键讨论点
 
@@ -64,7 +64,7 @@ v2.0 首页改版确定采用方案 2（低风险迭代 + A/B Test），下周
 
 - 需求：在应用内增加反馈入口（替代当前的邮件反馈）
 - 小李评估：技术可行，前端开发约 1.5 周
-- 阻塞：设计稿预计 3/26 才能完成，开发需等设计
+- 阻塞：设计稿要到下周三才能完成，开发需等设计
 
 ### 首页性能
 
@@ -74,11 +74,11 @@ v2.0 首页改版确定采用方案 2（低风险迭代 + A/B Test），下周
 
 ## 遗留问题
 
-- **暗色模式**：老张提出探索意向，但团队一致认为优先级低于当前需求。暂缓，视 v2.0 完成情况决定是否纳入 v2.1
+- **暗色模式**：老张提出探索意向，但团队一致认为优先级低于当前需求，先暂缓
 
 ## 下次会议
 
-**时间**：3/26（周三）14:00 | **议题**：性能排查结果汇总 + 反馈模块设计评审
+**时间**：[待确认] | **议题**：性能排查结果汇总 + 反馈模块设计评审
 ```
 
 ---
diff --git a/skills/performance-review/examples.md b/skills/performance-review/examples.md
index 1b3f20d..b4f62a6 100644
--- a/skills/performance-review/examples.md
+++ b/skills/performance-review/examples.md
@@ -29,7 +29,7 @@
 
 ## 核心总结
 
-本周期 3 项 OKR 全部达成（其中 1 项超额完成 108%），额外推动 CI/CD 优化和慢 SQL 检测两项基础设施改善，直接影响团队全员开发效率。
+本周期 3 项目标全部达成，其中 Bug 响应时间目标超额完成；同时额外完成了 CI/CD 优化和慢 SQL 检测两项基础设施改进。
 
 ## 目标达成情况
 
@@ -43,11 +43,11 @@
 | 评估 | 🟢 达成 |
 
 **具体成果**：
-- 完成从 Session 到 JWT + SSO 的全面迁移，支持邮箱、手机号、企业 SSO 三种登录方式
-- 28,000 名存量用户无缝迁移，迁移过程零数据丢失
-- SSO 登录成功率 99.2%，超过行业平均水平（~97%）
+- 完成从原有登录方案到 JWT + SSO 的迁移并上线
+- 覆盖 28,000 用户
+- SSO 登录成功率 99.2%
 
-**业务影响**：统一登录体系为后续多产品线共用同一账户体系奠定基础，预计减少用户流失率 5-8%（用户不再需要重复注册）
+**业务影响**：统一登录体系为后续账号体系整合打下基础。
 
 ### 目标 2：Bug 修复响应时间缩短 30%
 
@@ -59,11 +59,10 @@
 | 评估 | 🟢 超额完成 |
 
 **具体成果**：
-- 建立了 Bug 分级响应机制：P0 即时、P1 4小时、P2 24小时
-- 引入 On-call 轮值制度，保证工作时间内有人值守
+- 建立了更快的 Bug 响应机制
 - 响应时间从 48 小时降至 18 小时，超目标 108%
 
-**业务影响**：客户投诉率下降 35%，客服团队反馈"技术支持响应速度显著改善"
+**业务影响**：更快的响应时间降低了问题积压风险。
 
 ### 目标 3：培养 1 名新人独立负责模块
 
@@ -71,28 +70,28 @@
 |------|------|
 | 目标 | 培养小李具备独立负责模块的能力 |
 | 结果 | 小李已独立负责消息模块 |
-| 关键数据 | 独立上线 2 个功能 · 零 P0 事故 · Code Review 通过率从 40% 提升至 85% |
+| 关键数据 | 独立上线 2 个功能 · 零 P0 事故 |
 | 评估 | 🟢 达成 |
 
 **具体成果**：
-- 制定了为期 3 个月的培养计划（周 1:1 + 渐进式交接）
-- 小李从需要逐行 Review 到独立设计并上线 2 个功能，Code Review 通过率从 40% 提升至 85%
-- 团队对小李的信任度提升，已能独立处理 P1 级 Bug
+- 通过持续带教和任务交接，帮助小李逐步独立负责模块
+- 小李已独立负责消息模块
+- 已上线 2 个功能且无 P0
 
-**业务影响**：团队"巴士因子"从 1 提升至 2（消息模块不再是单点），降低人员风险
+**业务影响**：团队对消息模块的人员风险更可控，不再完全依赖单人。
 
 ## 额外贡献（超出目标范围）
 
-- **CI/CD 流水线优化**：主动发现构建时间过长的痛点，通过缓存优化和并行化将构建时间从 12 分钟降至 4 分钟（-66%）。按团队每天平均 20 次构建计算，每日节约 160 分钟等待时间
-- **慢 SQL 检测工具**：开发了内部自动化扫描工具，扫描全量 SQL 发现 15 个潜在慢查询，其中 3 个在高流量下可能导致超时。已全部优化
+- **CI/CD 流水线优化**：将构建时间从 12 分钟降至 4 分钟（-66%）
+- **慢 SQL 检测工具**：开发内部工具并发现了 15 个潜在问题
 
 ## 成长与反思
 
 **成长点**：
-- 系统学习了 Kubernetes，获得 CKA（Certified Kubernetes Administrator）认证，并在用户中心项目中实践了容器化部署
+- 系统学习了 Kubernetes，并获得 CKA（Certified Kubernetes Administrator）认证
 
 **待改进**：
-- 跨团队需求沟通：本周期有 2 次因需求理解偏差导致返工（消息模块优先级排序、SSO 错误码规范）。改进计划：需求评审阶段增加书面确认环节，关键需求做 5 分钟复述确认
+- 跨团队需求沟通仍有提升空间。改进计划：需求评审阶段增加书面确认环节，关键需求做 5 分钟复述确认
 
 ## 下一周期目标
 
diff --git a/skills/project-update/examples.md b/skills/project-update/examples.md
index b88e33c..7b656a2 100644
--- a/skills/project-update/examples.md
+++ b/skills/project-update/examples.md
@@ -38,41 +38,41 @@
 
 | 里程碑 | 计划完成 | 实际完成 | 状态 |
 |--------|---------|---------|------|
-| 需求评审 | 2/15 | 2/14 | ✅ 已完成 |
-| 技术方案 | 2/28 | 3/3 | ✅ 已完成（延迟 3 天） |
-| 开发 | 3/25 | — | 🔄 进行中 (60%) |
-| 联调 | 4/5 | — | ⏳ 未开始 |
+| 需求评审 | [待确认] | 已完成 | ✅ 已完成 |
+| 技术方案 | [待确认] | 已完成 | ✅ 已完成 |
+| 开发 | [待确认] | — | 🔄 进行中 (60%) |
+| 联调 | [待确认] | — | ⏳ 未开始 |
 | 上线 | 4/15 | — | ⏳ 预计 4/22 |
 
 **总体进度**：65% 完成 | 原计划上线：4/15 | 当前预计：4/22（延迟 ~1 周）
 
 ## 本阶段完成
 
-- 用户认证模块开发完成，支持邮箱 + 手机号双通道登录
-- SSO 集成框架搭建完成，OAuth 2.0 流程已通
-- 用户迁移脚本完成首版，覆盖现有 28,000 用户数据
+- 需求评审已完成
+- 技术方案已完成
+- 开发进行中，当前约 60%
 
 ## 风险矩阵
 
 | 风险 | 概率 | 影响 | 状态 | 应对措施 |
 |------|------|------|------|---------|
-| SSO 供应商接口不稳定（本周超时 3 次） | 高 | 联调延迟 3-5 天 | 🔴 未解决 | 已向供应商提工单；备选方案：本地缓存 Token 降级 |
-| 前端人力缺口（小王 3/24-4/7 休假） | 确定 | 前端进度放缓 40% | 🟡 待决策 | 方案A：加外包 ¥3万/月；方案B：后端兼顾部分前端 |
+| SSO 供应商接口不稳定（本周超时 3 次） | 高 | 联调延迟 3-5 天 | 🔴 未解决 | 已向供应商提工单；备选方案待确认 |
+| 前端人力缺口（小王下周开始休假 2 周） | 确定 | 可能进一步拉长前端开发周期 | 🟡 待决策 | 方案A：加外包；方案B：内部协调人力 |
 
 ## 资源状况
 
 | 角色 | 需求 | 到位 | 缺口 |
 |------|------|------|------|
-| 后端 | 3 | 3 | 充足 |
-| 前端 | 2 | 2 → 3/24 起降为 1 | 3/24 起缺 1 人 |
+| 团队总人数 | 5 | 5 | 当前负荷较高 |
+| 前端 | [待确认] | 下周起少 1 人 | 存在缺口 |
 
 ## 需要决策
 
 1. **是否增加 1 名外包前端？**
-   - 方案 A（推荐）：增加外包，¥3 万/月，覆盖小王休假期间的前端任务，保住 4/22 上线
-   - 方案 B：不增加，由后端同学兼做简单前端，上线可能进一步延迟至 4/30
-   - **截止**：3/21（外包公司需 2 天准备人选）
-   - **不决策后果**：每延迟 1 天，影响后续 Q2 计划排期
+   - 方案 A（推荐）：增加外包前端，覆盖休假期间的任务缺口
+   - 方案 B：不增加，由现有团队内部协调
+   - **截止**：下周前
+   - **不决策后果**：项目上线时间可能进一步延迟
 ```
 
 ---
diff --git a/skills/proposal/examples.md b/skills/proposal/examples.md
index b89a1ee..4189b92 100644
--- a/skills/proposal/examples.md
+++ b/skills/proposal/examples.md
@@ -27,25 +27,24 @@
 
 ## 执行摘要
 
-当前部署全手动，每次耗时 4 小时，每月上线 8 次，上周因人为失误引发 P1 事故影响 2,000 用户。建议引入 GitHub Actions + ArgoCD 自动化部署，投入 2 名工程师 3 周 + $500/月基础设施成本，将单次部署时间从 4 小时降至 15 分钟，消除人为操作错误。预计 4 个月内回收投资。
+当前部署全手动，每次耗时 4 小时，每月上线 8 次，上周因人为失误引发 P1 事故影响 2,000 用户。建议引入 GitHub Actions + ArgoCD 自动化部署，投入 2 名工程师 3 周 + $500/月基础设施成本，将单次部署时间从 4 小时降至 15 分钟，并显著降低人为操作风险。
 
 ## 问题描述
 
 ### 现状
 
-- 每次部署耗时 **4 小时**，涉及 12 步手动操作
+- 每次部署耗时 **4 小时**
 - 每月上线 **8 次**，合计 **32 人·小时/月** 用于部署
-- 上周（3/12）因手动操作失误引发 **P1 事故**：错误的环境变量配置导致支付接口中断 30 分钟，影响 2,000 名用户
-- 本年度已发生 **3 次** 部署相关线上问题
+- 上周因手动操作失误引发 **P1 事故**，影响 2,000 名用户 30 分钟
 
 ### 不行动的代价
 
 | 维度 | 影响 |
 |------|------|
-| 时间成本 | 每月 32 人·小时浪费在手动部署上（≈ $4,800/月，按 $150/小时人力成本） |
-| 事故风险 | 年均 6 次部署事故（按当前频率），每次影响 1,000-5,000 用户 |
-| 团队影响 | 资深工程师花 40% 时间在部署而非开发上，影响留存 |
-| 机会成本 | 部署繁琐导致团队倾向于减少上线频率，拖慢迭代速度 |
+| 时间成本 | 每月 32 人·小时用于手动部署 |
+| 事故风险 | 手动流程已经发生过 P1 事故 |
+| 团队影响 | 工程时间持续被重复部署工作占用 |
+| 机会成本 | 部署繁琐会拖慢上线节奏 |
 
 ## 建议方案
 
@@ -65,46 +64,45 @@
 
 | 资源 | 数量 | 成本 | 说明 |
 |------|------|------|------|
-| 工程师人力 | 2 人 × 3 周 | $13,500（机会成本） | 按 $150/小时 × 45 小时/人 |
-| GitHub Actions | — | 已含在现有 GitHub 订阅中 | $0 增量 |
+| 工程师人力 | 2 人 × 3 周 | [待确认] | 机会成本需按团队实际人力成本计算 |
+| GitHub Actions | — | [待确认] | 是否有增量成本取决于现有套餐 |
 | ArgoCD 基础设施 | — | $500/月 | K8s 集群内运行 |
-| **合计（首年）** | | **$19,500** | 一次性 $13,500 + 运营 $6,000/年 |
+| **合计（首年）** | | **[待确认]** | 需补充人力成本后计算 |
 
 ## ROI 分析
 
 | 项目 | 金额 |
 |------|------|
-| 总投入（首年） | $19,500 |
-| 年度节约——人力时间 | $57,600（32 小时/月 × $150/小时 × 12 月） |
-| 年度节约——事故减少 | ~$15,000（预计减少 90% 部署事故） |
-| **年度净收益** | **$53,100** |
-| 回收期 | **~4 个月** |
-| 3 年 ROI | **730%** |
+| 总投入（首年） | [待确认] |
+| 年度节约——人力时间 | 32 小时/月 × 12 = 384 小时/年 |
+| 年度节约——事故减少 | 可预期下降，但需补充事故成本后再量化 |
+| 回收期 | [待确认] |
+| 3 年 ROI | [待确认] |
 
 ## 方案对比
 
 | 维度 | GitHub Actions + ArgoCD（推荐） | Jenkins | 不做 |
 |------|------|---------|------|
-| 一次性成本 | $13,500 | $18,000（需额外服务器） | $0 |
-| 月运营成本 | $500 | $800 | $0（但隐性 $4,800/月） |
+| 一次性成本 | [待确认] | [待确认] | $0 |
+| 月运营成本 | $500 + 其他待确认成本 | [待确认] | $0（但有人工时间成本） |
 | 实施周期 | 3 周 | 5 周 | — |
-| 维护负担 | 低（SaaS + 云原生） | 高（需自行维护 Jenkins 服务器） | — |
-| 社区前景 | 活跃，GitHub 官方维护 | 萎缩，核心贡献者减少 | — |
-| 长期风险 | 低 | 中（维护成本递增） | 高（事故频率递增） |
+| 维护负担 | 较低 | 较高 | 高 |
+| 社区前景 | 活跃 | 较成熟但维护成本更高 | — |
+| 长期风险 | 中低 | 中 | 高 |
 
 ## 风险与缓解
 
 | 风险 | 概率 | 缓解措施 |
 |------|------|---------|
 | 迁移期间部署中断 | 低 | 新旧并行运行 1 周，验证稳定后切换 |
-| 学习曲线 | 低 | 团队已有 K8s 基础，ArgoCD 文档完善 |
+| 学习曲线 | 中 | 团队需要补充 GitHub Actions 和 ArgoCD 的使用规范 |
 | 自动化引入新类型故障 | 中 | 生产部署保留人工审批门 + 自动回滚 |
 
 ## 决策请求
 
-- **请求**：批准 2 名工程师（张工、刘工）未来 3 周投入 CI/CD 建设 + $500/月基础设施预算
+- **请求**：批准 2 名工程师未来 3 周投入 CI/CD 建设 + $500/月基础设施预算
 - **截止**：3/25（越早开始，越早消除手动部署风险）
-- **延迟决策影响**：每推迟 1 个月 = 多浪费 $4,800 人力 + 持续承担部署事故风险
+- **延迟决策影响**：继续保留手动部署成本，并持续承担人为操作事故风险
 ```
 
 ---