RedGranite build-vs-buy：少造轮子
何时用
需求或需求的一部分看起来"别人也需要"时。
硬规则
- MUST 写代码前查三层：官方 SDK → 成熟开源库 → 可购买的产品。每层写一行查到什么。
- MUST 需求涉及让 agent 调用某个成熟产品时，先查该产品是否已提供官方 MCP server；有则直接接入，不自写工具封装其 API。
- MUST 把需求拆成 commodity（别人做得比我们好）与 core differentiation（我们存在的理由），只对后者自研。
- NEVER 因"库太重""想自己控制"重写成熟实现，除非给出可测量理由（体积、许可证、缺失功能）。
- MUST 自研范围写成一句边界："只做 X，Y 与 Z 用 __"。
- MUST 复杂任务中，某步骤由人工完成（看一眼、点一下、给个值）能省大量时间或复杂度时，先向用户说明这项权衡再动手；用户拒绝则照做，不自行决定。
- NEVER 为未来可能的替换提前抽象适配层；直接用库的接口。
审问清单
- 有官方 SDK 吗？版本、语言支持？
- 开源库：最近提交、许可证、覆盖我们的需求几成？
- 有可直接买的产品吗？价格与自研人天比？它有官方 MCP server 吗？
- 我们的 core differentiation 是什么？这个能力在其中吗？
- 自研的话，一年后谁维护？
- 库不够的部分能靠配置或薄包装解决吗？
- 哪一步人工做只要一分钟、自动化却要半天？说了吗？
反模式
- 错误：自写 JWT 签发与校验。→ 正确：用 jose / PyJWT 等主流库，自研只剩 claims 定义。
- 错误：自写 Markdown 解析器"因为只要几个功能"。→ 正确：用 markdown-it / mistune，禁用不需要的规则。
- 错误：为将来可能换数据库写 Repository 抽象层。→ 正确：直接用 ORM，真要换时再抽。
- 错误：让 agent 查 GitHub issue，自写一组调 REST API 的工具函数。→ 正确：接官方 GitHub MCP server。
- 错误：为拿一个验证码写整套 OAuth 回调 + 邮箱轮询。→ 正确：先说"你贴一下验证码，省两小时"，用户同意就等，不同意再写。
输出要求
一张表：能力 | commodity / core | 方案（SDK / 库 / 产品 / 自研） | 依据一句。