# 文章模板 · 项目深度分析

> 使用方式：复制本文件为 `articles/<id>.md` 后逐节填写。
> 带 `【必填】` 的章节不可省略；带 `【若适用】` 的可按项目情况取舍。
> **写作铁律：不做 README 复读机。** 每一节都要回答「README 没写、但你核实出来了什么」。

---

# <项目名>：<副标题，点出它真正有意思的那个点>

> **速览**
> | 项 | 值 |
> | --- | --- |
> | 仓库 | [owner/name](url) |
> | 一句话 | <tagline> |
> | Star / Fork / Issues | <n> / <n> / <n>（截至 <日期>） |
> | 主语言 / 体积 | <lang> / <size> |
> | 许可证 | <name>（L<n> · <成色>） |
> | 成熟度 | <preview/beta/stable> |
>
> 一句话结论：<verdict.one_liner>

---

## 0. 先给结论 【必填】

用 3-5 句话说清：它是什么、不是什么、最值得关注的一点。
**不要在这里复述特性列表**——读者要的是判断，不是目录。

---

## 1. 赛道定位：它站在哪一层 【必填】

把它放进坐标系。建议按 Agent 工具的三层栈定位：

- **执行引擎层**（Codex / DeepSeek Harness / OpenCode …）—— 真正跑 agent loop 的地方
- **编辑器内 Agent 层**（Cline / Roo Code / Kilo Code …）—— 嵌在 IDE 里的交互层
- **桌面工作台层**（iPolloWork 等）—— 跨引擎、跨项目、跨交付物的统一界面

写明它跨了几层、以哪一层为主。**配一张分层图。**

---

## 2. 业务维度：它靠什么活着 【必填】

- 目标用户到底是谁（警惕「人人可用」这种说法）
- 变现路径：捐赠 / 商业授权 / SaaS / 双轨 / 尚未明确
- 许可证成色分析：**这是本节重点**。不只是写许可证名，要说清
  - 它是 OSI 认证的吗？不是的话，差在哪？
  - 关键限制条款是什么（用户/规模/再分发/品牌保留）
  - 这个限制的商业意图是什么
- 护城河：什么是别人抄不走的

---

## 3. 场景维度：它在什么场合被用 【必填】

- 核心场景与典型用例（给具体例子，别写「提升效率」这类空话）
- 人机协作模式：全自动 / 审批式 / 全程监督
- **交付物**：它最终产出什么？这些产出生成后还能改吗？
  （这是区分「生成工具」和「工作台」的关键分水岭）

---

## 4. 技术维度：它怎么做到的 【必填】

- 产品形态与技术栈
- **架构图**（必须有，用 ASCII 或 SVG）
- monorepo 布局 / 模块职责拆解
- **引擎抽象层**：如果它支持多引擎，逐个说明接入方式，
  并明确指出**各引擎的接入深度是否对等**
  （常见落差：A 是原生 adapter，B 只是 MCP 控制面）
- 扩展机制：Skills / 插件 / MCP 是否统一生命周期
- 模型绑定程度：锁定自家模型 / 自带模型 / 完全中立
- 本地优先的实现方式（BYOM？数据不出本地？云端是否可选？）
- 权限审批与沙箱

---

## 5. 横向对比 【必填，项目数 ≥2 时】

与已收录项目的差异对照表。**不要只比功能清单**，要比设计取向：

| 维度 | 本项目 | 对照 A | 对照 B |
| --- | --- | --- | --- |
| 站位层次 | | | |
| 引擎立场 | | | |
| 交付物纵深 | | | |
| 许可证 | | | |

---

## 6. 宣称 vs 实测 【必填 · 本节是全篇价值核心】

逐条列出。每项必须写清：**宣称 / 实际 / 证据来源**。

撰写要点：
- 优先抓 README 里的限定词（`currently` / `today` / `in development` / `optional`）
  —— 这些词往往是落差的藏身处
- 对比第三方评测与官方自述的出入
- 用指标佐证叙事（版本号跳跃速度、仓库体积、issue 积压、最后提交时间）
- topics / 徽章里提到了但文档没写的，单独拎出来问

示例格式：
> **宣称**：兼容 Codex。
> **实际**：Codex 通过 `ipollowork-ui-mcp` 的 MCP 控制面接入，README 自述
> 「currently uses the MCP control surface rather than claiming a native Codex engine adapter」，
> 与 OpenCode 的原生 Engine Protocol adapter 深度不对等。
> **来源**：仓库 README *Architecture boundary* 一节。

---

## 7. 结论：什么人该用它 【必填】

- **该用**：<画像 + 场景>
- **不该用**：<画像 + 原因，比"该用"更重要>
- **再看看**：<哪些承诺落地后再评估>

---

## 8. 追踪备注 【必填】

- 数据日期：<日期>
- 指标来源：GitHub API（自动化快照）
- 下次跟进点：<列出需要持续观察的 2-3 件事，如「DSH 集成是否进入稳定版」>
- 相关档案：`data/projects/<id>.yaml` · 源码镜像：<gitea_repo>（<visibility>）

---

<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见 [系列索引](总纲链接) · 数据与脚本开源于 `gitinbox/agent-radar`</sub>