131 lines
4.7 KiB
Markdown
131 lines
4.7 KiB
Markdown
# 文章模板 · 项目深度分析
|
||
|
||
> 使用方式：复制本文件为 `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>
|