Files

4.7 KiB
Raw Permalink Blame History

文章模板 · 项目深度分析

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


<项目名>:<副标题,点出它真正有意思的那个点>

速览

项 值
仓库 owner/name
一句话
Star / Fork / Issues / / (截至 <日期>)
主语言 / 体积 /
许可证 (L · <成色>)
成熟度 <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>()

本文为「全球智能体开源应用追踪」系列之一 · 总纲见 系列索引 · 数据与脚本开源于 gitinbox/agent-radar