如何贡献

欢迎 纠错 / 补案例 / 改方法最低门槛 提一个 issue协议 MIT

这本指南是一个开源项目，欢迎任何人参与。你不需要是 FDE 专家，也不需要会写代码。一个准确的纠错，比一篇宏大的文章更有价值。

你可以怎么贡献

1. 纠错（最简单）

如果你发现事实错误、数据过时、来源不实、错别字、失效链接，请提一个 issue，或者直接改：

• 标题写明「纠错：哪一章 / 哪一句」；
• 说明原文是什么、应该是什么；
• 附上来源（链接、报告名、日期）。

2. 补案例

我们欢迎真实、可公开、有出处的 FDE / AI 落地案例。一个好的案例应该包含：

• 背景：什么行业、什么规模、什么阶段；
• 问题：原来的流程、痛点、基线；
• 做法：FDE 或团队具体做了什么；
• 结果：指标、时间、成本（注明口径）；
• 教训：可迁移的经验，以及不适用的边界；
• 来源：官方、媒体、访谈，至少一个可点击/可查证的出处。

请勿提交：未脱敏的客户数据、未公开的商业秘密、无法核实的「朋友说」、纯软文。

3. 改进方法

模板、练习、Lab、面试题、图示都欢迎。改动方法时，请说明：

• 原来的方法有什么问题；
• 新方法解决了什么问题；
• 有没有真实使用过，效果如何。

4. 翻译 / 传播

欢迎把核心章节翻译成其他语言，或做成课程、读书会。请保留出处与许可证。

内容规范

写作风格

• 中文简体，第二人称「你」，集体自称「我们」；
• 短段落，具体动作优先于抽象概念；
• 术语第一次出现给英文原文；
• 不写「赋能」「抓手」「闭环」这类没有具体动作的词；
• 每章尽量有：导语、现场片段（如为合成，明确标注）、正文、小结、练习、资料来源。

事实与来源

• 双源优先：能交叉验证的，至少两个来源；
• 单源标注：只有一个来源的，写「单一来源」「据报道」；
• 区分口径：公司披露 / 第三方估算 / 媒体报道 / 综合叙述；
• 不编造：客户名、金额、引语、URL、论文、数据；
• 不确定就标：写「待核」，或者删掉。

文件格式

• Markdown，UTF-8，LF 换行；
• 页面开头有 frontmatter：

---
title: 页面标题
description: 一句话描述
---

• 站内链接使用相对路径（同一目录）或 /guide/... 这类绝对路径；
• 图片放在 docs/public/，用 /xxx.svg 引用；
• 不要使用 Mermaid（当前站点未配置渲染），用 ASCII 图或表格。

本地开发

需要 Node.js 20+。

git clone https://github.com/sddzlsc/fde.git
cd fde
npm install
npm run docs:dev      # 本地预览，默认 http://localhost:5173/fde/
npm run check         # 检查章节结构、占位符、字数
npm run docs:build    # 构建静态站点

构建产物在 docs/.vitepress/dist/。

PR 流程

1. Fork 仓库，从 main 建分支：git checkout -b fix/chapter-04-typo；
2. 修改内容，本地跑 npm run check 和 npm run docs:build；
3. 提交 PR，说明：改了什么、为什么改、涉及哪些来源；
4. 维护者会检查事实、口径、链接和结构；
5. 合并后自动部署到 GitHub Pages。

提交信息建议

fix: 修正第 4 章 API 示例的返回字段
feat: 新增 John Deere 案例的订阅定价说明
docs: 更新第 9 章面试题参考答案

审稿标准

一个 PR 会被优先合并，如果它：

• 有明确来源，且来源可查；
• 区分事实与判断；
• 不夸大、不营销；
• 与现有章节风格一致；
• 没有破坏链接或构建。

一个 PR 可能会被拒绝，如果它：

• 无法核实；
• 是软文或招生广告；
• 大段复制他人内容；
• 引入未经脱敏的客户数据；
• 只改措辞、不改事实，且没有说明理由。

行为准则

参与本项目即表示你同意遵守 CODE_OF_CONDUCT.md。我们希望对事不对人，允许尖锐的技术批评，不允许人身攻击。

第一次贡献？

如果你不确定从哪里开始，可以：

• 找一个标有 good first issue 的 issue；
• 从「纠错」开始，哪怕只是一个错别字；
• 在 Discussions / issue 里提问，说明你想做什么。

感谢你让这本指南变得更好。