1. 为什么我会让DeepSeek来总结chDB的开发历程熟悉我的朋友知道chDB这个项目我断断续续维护了挺长时间。它本质上是把ClickHouse包装成一个SQLite兼容的嵌入式数据库让开发者可以用SQLite那套熟悉的API直接享受到ClickHouse的列式存储和分析性能。这个定位听起来简单但真正把SQLite的C接口语义、ClickHouse的执行引擎、内存管理、数据文件格式这几层东西缝在一起中间踩过的坑能写满一本手册。项目做到后期我面临一个很现实的问题代码仓库里的commit信息非常零散有些决策当时只是在PR讨论里提了一嘴有些架构调整的动机埋在一封邮件或者一个issue回复里。新的贡献者来问“为什么这里有这个限制”“为什么当初不用SQLite而选ClickHouse”我需要花大量时间翻聊天记录。更麻烦的是我自己时隔几个月回看某段代码时也会忘记当初为什么要绕这么一圈。后来我开始尝试用DeepSeek来做这件事把git历史、PR描述、issue讨论、关键邮件等素材全部导出来用精心设计的提示词让DeepSeek去梳理时间线、提炼决策背景、总结技术难点。这个方案听起来没有多玄乎但真正做下来效果出乎意料地好而且有几个细节值得单独拿出来说。这篇文章我就完整记录一下这条路是怎么走通的包括素材准备、提示词设计、结果校验以及一些我之前没在别处提过的教训。如果你是独立开发者、开源项目维护者或者只是希望把自己过去半年、一年的工作记录整理成一篇像样的复盘报告这整套流程都直接可以复用到你的项目上。并不需要什么特别的工具一台电脑、一个仓库、一个DeepSeek账号就够了。2. 先把材料备齐从仓库里捞出“开发历程”的原始素材2.1 别指望AI凭空知道你的项目很多人用AI写总结上来就问“帮我总结一下chDB的开发历程”然后期待AI输出一篇完美的技术复盘。但DeepSeek的训练数据里可能有ClickHouse的知识绝对不可能有你仓库里那些具体的commit和讨论细节。想让AI输出真实、有深度的项目历程第一步永远是喂素材。我在实际操作中会导出三类原始数据缺一不可Git提交历史包括commit的哈希、日期、作者、完整提交说明。这里我强调“完整提交说明”因为很多项目只保留第一行subject但真正的决策信息往往在body里。PR与Issue记录Pull Request的描述、Review评论、Issue里的讨论串。这些是开发过程中讨论最集中的地方包含大量“为什么这么做”“为什么不那么做”的一手信息。版本发布记录与内部文档CHANGELOG、docs目录下的设计文档、周报、甚至你个人博客里写过的某篇开发笔记。导出Git提交历史我常用两种方式取决于素材量大小。如果提交数量不大直接git log --all --dateshort --prettyformat:%h|%ad|%an|%s%n%b%n---输出到文本文件即可。如果历史很长比如几百上千条commit我建议还是拆成几个阶段分别导出避免一份文件过大导致AI处理时上下文溢出或者注意力分散。这里有一个非常重要的小技巧清洗素材时保留尽量多的原始上下文但把无关噪音去掉。比如提交说明里的Co-Authored-By、Signed-off-by这些尾部信息可以删掉但讨论串里“用户说这个API在Windows上不可用”这种看似不起眼的信息反而是后续总结技术约束的关键素材千万不要为了“干净”而删掉。2.2 素材的组织顺序按时间还是按模块这个问题我纠结过好几个版本。按时间排序是开发历程最自然的组织方式但我后来发现单纯的按时间排序会让AI迷失在琐碎的提交细节里因为它分不清哪些提交是里程碑级别的架构调整哪些只是修了个typo。现在我的做法是先把素材按“阶段”分组再做时间排序。比如chDB我大致分成“原型验证”“SQLite兼容层设计”“执行引擎优化”“稳定性和发布”这几个阶段。每个阶段给AI一小段背景说明再附带该阶段对应的commit、PR、issue日志。这样做的理由很朴素开发历程不只是时间线而是“几个关键阶段里的关键决策”。如果AI能在每个阶段的最开始就知道这个阶段的整体目标它生成的结构化总结就会更有逻辑。比如原型阶段AI会特别关注“为什么选择了ClickHouse而不是DuckDB”兼容层设计阶段它会关注“如何处理事务语义差异”优化阶段它会关注“哪些查询模式暴露了性能问题”。给一个我实际用过的素材组织模板01_prototype/README、最初的实验代码说明、两三条关键commit02_compat_layer/SQLite C API相关PR描述、兼容性测试报告03_optimization/性能分析文档、Benchmark结果、优化相关commit04_release/CHANGELOG、发布公告、用户反馈issue摘录每个阶段文件夹里放一个context.md用三五句话描述这个阶段的目标和最终产出。让AI在读具体素材之前先读这个上下文说明总结质量会明显上一个台阶。3. 提示词设计让DeepSeek不只是总结而是“复盘”3.1 提示词拆解角色、任务、约束、产出格式直接给DeepSeek扔一堆素材然后问“总结一下”生成结果通常中规中矩能列出时间线和几件事但缺乏洞察。如果想让AI真正像一位资深开发者那样复盘提示词里必须显式设置四个组件角色、任务、约束、产出格式。我实际使用的一个比较有效的提示词框架是这样的你是一位拥有多年经验的嵌入式数据库开发者同时也是这个项目的维护者。 请基于我提供的素材完成以下任务 1. 梳理chDB从立项到当前版本的整体开发时间线。 2. 提取每个阶段的关键技术决策并分析决策背后的原因。 3. 指出每个阶段遇到的主要技术难点和最终解决方案。 4. 总结这个过程中走弯路的地方如果能从素材中推断出 “如果重来一次会怎么做”请单独说明。 约束条件 - 所有结论必须从素材中推导不得补充素材之外的技术事实。 - 如果素材中有冲突信息请指出冲突并说明你采用了哪一方。 - 不要输出泛泛而谈的内容每个结论尽量关联具体的commit哈希或PR编号。 - 语气要像一位工程师在写项目复盘报告避免营销和夸大措辞。 产出格式要求 - 第一部分开发阶段总览用表格列出阶段、时间范围、核心目标 - 第二部分按阶段展开的关键决策记录 - 第三部分难点与解决过程 - 第四部分经验与教训如果素材中有据可查这个提示词看起来长但它每个部分都有明确目的。设置“嵌入式数据库开发者”角色是让AI自动切换到技术专家的语料体系减少泛泛的措辞。强调“从素材中推导”和“关联commit哈希”是为了抑制AI幻觉让它老老实实基于事实工作。要求表格和分部分结构则是为了让生成结果直接可用于文档沉淀省去二次整理。3.2 迭代式对话先框架后细节一次对话就拿到完美总结的情况很少见我现在的习惯是多轮迭代。第一轮只让DeepSeek产出一个阶段总览和大纲确认结构合理后再逐段深入。这样做的原因是开发历程里的因果关系经常是隐性的——某个阶段的设计决策可能要到很久以后才显示出影响AI如果一开始就把细节全部展开很容易只见树木不见森林。我第二轮通常这样追问“第一阶段里你提到了兼容层设计这部分的commit记录里有哪些反复重构请聚焦在SQLite事务语义和ClickHouse复制表的冲突上看看当时的解决思路是否经历了两轮以上调整。”这种带具体焦点的追问会让AI回到素材中寻找更深层的关联而不是复述已有结论。另外一个好用的追问方向是“请尝试用一个新贡献者的视角重新描述这个阶段。”这个要求会让AI主动补充“背景知识”和“入坑指引”输出内容反而更像一篇对社区有用的技术日志。开发历程总结给谁看直接决定了内容深浅。维护者自己看要的是决策回忆新贡献者看要的是背景和约定外部用户看要的是能力和边界。这个视角切换DeepSeek做得比我预期的好很多。3.3 让AI区分“事实”和“观点”这是我在反复迭代中总结出来的一个实用设计。开发历程总结里“事实”和“观点”必须清楚分开否则很容易把当时的情绪或者不成熟的判断当成经过验证的经验写进文档。我会在提示词里加一条“如果素材中出现评价性语言比如‘这个方案更优雅’‘性能提升明显需要量化’请标注为主观描述并尽量寻找量化证据找不到就注明‘仅为主观观点’。”比如chDB里有一个关于内存映射文件的决策当时团队内部争论过“映射整个文件”和“按需分页加载”两种方案。提交记录里既有性能测试的数字也有“后者实现更清爽”这样的个人偏好。AI如果能把数字和评价性语言分开呈现这个决策的参考价值就完全不同。这个约束并不复杂但效果很明显。生成出来的总结不会变成一篇“所有事情都很顺利”的流水账而是能让人看出哪些判断经过了验证、哪些还停留在直觉层面。4. 全流程实操从一堆散乱素材到一篇可发布的开发历程4.1 分步操作实录这里我记录一次比较典型的完整流程你可以直接照着走。第一步导出原始素材。在chDB仓库根目录执行mkdir -p /tmp/chdb_history/logs git log --all --dateshort --prettyformat:%h|%ad|%an|%s%n%b%n--- /tmp/chdb_history/logs/commits.txt然后把PR和issue从GitHub页面导出或复制下来按阶段放入对应文件夹。这一步粗糙一点没关系关键是保证内容完整。我自己甚至会把某些特别有代表性的评论单独存成一份highlights.md方便后续重点投喂。第二步编写阶段上下文文件。比如context.md里我会写阶段原型验证时间范围起始到某次commit 目标验证ClickHouse能否作为嵌入式引擎嵌入SQLite兼容层 核心问题 1. ClickHouse的列式存储是否支持进程内嵌入 2. SQLite的字节码执行模型能否桥接到ClickHouse的向量化执行 3. 最小可行产品的边界在哪里 最终产出一个可以在内存中运行简单查询的原型实例这个文件不需要长但它给AI提供了理解散乱commit的“结构性锚点”。第三步分阶段投喂并生成框架。按“阶段一、阶段二……”的顺序把每个阶段的context.md和对应日志依次发送给DeepSeek每次都要求它输出“本阶段目标、关键commit、技术决策、主要难点”四块内容。全部阶段处理完后再让AI合并成整体开发时间线。第四步追问和校验。对每个阶段逐条提问比如“你提到这个阶段引入了预聚合方案对应的commit是哪几条当时的验收标准是什么”通过这种方式逼迫AI回到素材里找证据把每个结论钉死在具体记录上。4.2 从粗糙时间线到高质量博文的三轮打磨第一轮AI生成的东西通常是一份“能看但不够深入”的草稿。真正让它变成一篇可以发布的长文需要三轮打磨。第一轮打磨补全因果链。我要求AI对每个阶段回答三个问题当时的约束是什么做了哪个选择后来因为什么而调整这一步会把流水账变成有逻辑的叙事。比如早期chDB支持的是固定列数超过一定阈值就回退到全表扫描这个限制在后来的版本中通过谓词下推给绕过了。如果没有因果链这段经历看起来就是“先受限再优化”补全因果之后就是“因为存储引擎的块迭代器不支持可中断操作早期只能全表扫后来给迭代器加了中断标志位才让过滤条件下推到数据块级别”。后者才是有价值的开发经验。第二轮打磨压缩同质内容放大高光细节。AI生成的总结有一个毛病就是每个阶段篇幅差不多显得平铺直叙。我会手动指示它“这个阶段的内容压缩为30%那个阶段的技术难点展开并补充细节。”比如chDB里兼容层的事务语义处理是极难的一件事AI第一版可能只给了两句话但实际开发中我们花了几个星期跟SQLite的锁模型打交道。这时候我会给它真正相关的commit和讨论内容让它围绕这一件事写足、写透。第三轮打磨加入人的视角。AI产出的文本即使逻辑再顺也缺少那种“我当时其实很担心这样会不会出问题”的真实感。第三轮我会让AI帮我保留技术骨架然后自己动手补几条带情绪的批注。这不是为了文采而是让阅读者知道这份记录是活人写的是带着不确定性和真实权衡写出来的。5. 避坑清单与常见问题排查5.1 提示词与上下文相关的问题及对策AI编造commit哈希怎么办。这是最容易出现的幻觉。解决方案是在提示词里反复强调“所有结论必须关联你实际收到的commit列表中的条目不许自己生成哈希找不到就写‘素材未提供’”。另外生成结果里的引用要抽查手动对照一下原始提交记录确认前后的描述和真实commit信息吻合。AI把不同版本的方案混在一起。我会要求它“先按时间顺序确认方案A存在于某时刻方案B存在于某时刻然后对比”。如果素材时间跨度很大最好明确告诉AI各位commit的先后关系避免它把早期的废弃方案跟后来的定稿方案并列讨论。上下文太长导致AI开始忘事。一次性塞几十万字素材不现实DeepSeek上下文有限内容过长会导致中间素材被忽略或者总结质量下降。最有效的办法是先按阶段分批处理再让AI合并。合并的时候不要把所有细节再次粘贴而是把每阶段的总结文本汇总并对有衔接关系的地方做局部追问。5.2 提示词之外的工程性问题除了AI本身的问题还有几个工程层面的细节值得说一说。素材命名混乱。如果一份文件里既有commit日志又有PR描述日期还不统一AI梳理时间线时会很痛苦。我最后选择在每个阶段文件夹里统一使用YYYY-MM-DD_描述.txt的命名方式并且每条记录都带原始日期。这一步看似琐碎却直接决定了后续总结的时间线准确性。不要忽视Review评论。Review评论里通常藏着“这个代码为什么不能这么写”的硬约束这些信息在commit里往往没有。我在chDB的兼容层阶段就有一条重要的约束——“SQLite的游标必须能回滚但ClickHouse的block流不支持任意位置seek”这句话最初是在一次PR Review的十几条评论里逐渐浮出来的单看任何一条commit都看不到全貌。所以素材准备阶段PR Review评论一定要完整导出。权限与隐私。如果项目不在公开仓库注意不要直接把内部讨论记录完整发给任何外部工具做好脱敏处理。涉及用户隐私、未公开的商业决策等信息要先行剔除只保留技术相关内容。开发历程总结要的是技术见解和经验教训不需要原样传抄那些敏感的完整讨论。5.3 一些零碎的实战心得用DeepSeek做chDB开发历程总结我前后尝试了三个版本期间也总结出一些零碎但很管用的心得。不要每次都从零开始发提示词。我会维护一个prompt_template.md文件把角色设定、任务描述、约束条件和输出格式都存下来每次只替换项目和阶段名称。这样一致性好生成质量也更稳定。给AI一个“没有素材就直说”的许可。开发历程肯定是残缺的总有那么几周没有写commit消息有些决策找不到记录。允许AI坦诚地标注“此阶段资料缺失无法推断具体过程”比让它硬着头皮编一段靠谱得多。最终生成的总结里明确标注了缺失信息的部分反而显得更真实可信。同一个总结任务变换几次问法结果能带来很多新灵感。比如请AI“以新贡献者视角”“以用户视角”“以竞品开发者视角”各跑一遍不同视角下的侧重完全不同。新贡献者视角会想知道代码该往哪个模块加、哪些代码是核心路径用户视角更关心边界行为和限制约束竞品开发者视角则可能会直接问“你们为什么要选这条技术路线你们的妥协在哪里”。把这些不同视角的产物叠在一起能自动发现很多之前没有意识到的盲点。6. 从“留档”到“传播”开发历程的下一步利用开发历程总结完成之后我推荐做三件事回流文档、生成社区版本、持续迭代。回流文档是最直接的收益。把AI生成的开发历程里“关键决策记录”“技术难点过程”这两部分整理后并入项目的docs/development.md或者ARCHITECTURE.md。新维护者装机、写代码前先读这份文档遇到“为什么这里有这个兼容层”“为什么这个接口不能并发调用”之类的问题时至少有一个自查的入口而不是每次发issue或者私信找维护者问。生成社区版本则是一个很有意思的场景。面向社区发布的开发历程不需要内部版的全部细节反而要更侧重“这个项目解决了什么问题”和“这个项目怎么使用”。我让DeepSeek基于完整总结生成一版适合公开发布的文字删掉比较敏感的早期争论细节把篇幅重心放在对外可见的功能演进和约束说明上。社区反馈的每一条“你们为什么不做X”的issue我都可以从开发历程里找到当时的决策背景来回复省去了很多重复解释的成本。这个开发历程总结不是一次性工作。代码库每周都有新commit新决策每两个月就有一轮。比较好的做法是设定一个固定节奏比如每个重要版本发布之后把新增的commit、PR、issue喂给之前的总结结果让AI做增量更新。因为基础框架已经有了增量更新比从头写一遍要快得多质量也更稳定。从我自身的体验来看让DeepSeek来总结chDB开发历程真正价值并不是“省了写文档的时间”而是它提供了一种外部的、结构清晰的眼睛能看到我自己因为太熟悉项目而忽略的关联和模式。开发者在写总结时很容易陷入“凡走过的都是必经之路”的惯性叙事AI则会根据素材里的冲突、反复和缺漏把那些被我遗忘的弯路重新摆到桌面上来。这也让整个项目的发展路径变得比记忆中的版本更立体、更接近它本来的样子。 用DeepSeek总结chDB开发历程：从git历史到技术复盘实战
1. 为什么我会让DeepSeek来总结chDB的开发历程熟悉我的朋友知道chDB这个项目我断断续续维护了挺长时间。它本质上是把ClickHouse包装成一个SQLite兼容的嵌入式数据库让开发者可以用SQLite那套熟悉的API直接享受到ClickHouse的列式存储和分析性能。这个定位听起来简单但真正把SQLite的C接口语义、ClickHouse的执行引擎、内存管理、数据文件格式这几层东西缝在一起中间踩过的坑能写满一本手册。项目做到后期我面临一个很现实的问题代码仓库里的commit信息非常零散有些决策当时只是在PR讨论里提了一嘴有些架构调整的动机埋在一封邮件或者一个issue回复里。新的贡献者来问“为什么这里有这个限制”“为什么当初不用SQLite而选ClickHouse”我需要花大量时间翻聊天记录。更麻烦的是我自己时隔几个月回看某段代码时也会忘记当初为什么要绕这么一圈。后来我开始尝试用DeepSeek来做这件事把git历史、PR描述、issue讨论、关键邮件等素材全部导出来用精心设计的提示词让DeepSeek去梳理时间线、提炼决策背景、总结技术难点。这个方案听起来没有多玄乎但真正做下来效果出乎意料地好而且有几个细节值得单独拿出来说。这篇文章我就完整记录一下这条路是怎么走通的包括素材准备、提示词设计、结果校验以及一些我之前没在别处提过的教训。如果你是独立开发者、开源项目维护者或者只是希望把自己过去半年、一年的工作记录整理成一篇像样的复盘报告这整套流程都直接可以复用到你的项目上。并不需要什么特别的工具一台电脑、一个仓库、一个DeepSeek账号就够了。2. 先把材料备齐从仓库里捞出“开发历程”的原始素材2.1 别指望AI凭空知道你的项目很多人用AI写总结上来就问“帮我总结一下chDB的开发历程”然后期待AI输出一篇完美的技术复盘。但DeepSeek的训练数据里可能有ClickHouse的知识绝对不可能有你仓库里那些具体的commit和讨论细节。想让AI输出真实、有深度的项目历程第一步永远是喂素材。我在实际操作中会导出三类原始数据缺一不可Git提交历史包括commit的哈希、日期、作者、完整提交说明。这里我强调“完整提交说明”因为很多项目只保留第一行subject但真正的决策信息往往在body里。PR与Issue记录Pull Request的描述、Review评论、Issue里的讨论串。这些是开发过程中讨论最集中的地方包含大量“为什么这么做”“为什么不那么做”的一手信息。版本发布记录与内部文档CHANGELOG、docs目录下的设计文档、周报、甚至你个人博客里写过的某篇开发笔记。导出Git提交历史我常用两种方式取决于素材量大小。如果提交数量不大直接git log --all --dateshort --prettyformat:%h|%ad|%an|%s%n%b%n---输出到文本文件即可。如果历史很长比如几百上千条commit我建议还是拆成几个阶段分别导出避免一份文件过大导致AI处理时上下文溢出或者注意力分散。这里有一个非常重要的小技巧清洗素材时保留尽量多的原始上下文但把无关噪音去掉。比如提交说明里的Co-Authored-By、Signed-off-by这些尾部信息可以删掉但讨论串里“用户说这个API在Windows上不可用”这种看似不起眼的信息反而是后续总结技术约束的关键素材千万不要为了“干净”而删掉。2.2 素材的组织顺序按时间还是按模块这个问题我纠结过好几个版本。按时间排序是开发历程最自然的组织方式但我后来发现单纯的按时间排序会让AI迷失在琐碎的提交细节里因为它分不清哪些提交是里程碑级别的架构调整哪些只是修了个typo。现在我的做法是先把素材按“阶段”分组再做时间排序。比如chDB我大致分成“原型验证”“SQLite兼容层设计”“执行引擎优化”“稳定性和发布”这几个阶段。每个阶段给AI一小段背景说明再附带该阶段对应的commit、PR、issue日志。这样做的理由很朴素开发历程不只是时间线而是“几个关键阶段里的关键决策”。如果AI能在每个阶段的最开始就知道这个阶段的整体目标它生成的结构化总结就会更有逻辑。比如原型阶段AI会特别关注“为什么选择了ClickHouse而不是DuckDB”兼容层设计阶段它会关注“如何处理事务语义差异”优化阶段它会关注“哪些查询模式暴露了性能问题”。给一个我实际用过的素材组织模板01_prototype/README、最初的实验代码说明、两三条关键commit02_compat_layer/SQLite C API相关PR描述、兼容性测试报告03_optimization/性能分析文档、Benchmark结果、优化相关commit04_release/CHANGELOG、发布公告、用户反馈issue摘录每个阶段文件夹里放一个context.md用三五句话描述这个阶段的目标和最终产出。让AI在读具体素材之前先读这个上下文说明总结质量会明显上一个台阶。3. 提示词设计让DeepSeek不只是总结而是“复盘”3.1 提示词拆解角色、任务、约束、产出格式直接给DeepSeek扔一堆素材然后问“总结一下”生成结果通常中规中矩能列出时间线和几件事但缺乏洞察。如果想让AI真正像一位资深开发者那样复盘提示词里必须显式设置四个组件角色、任务、约束、产出格式。我实际使用的一个比较有效的提示词框架是这样的你是一位拥有多年经验的嵌入式数据库开发者同时也是这个项目的维护者。 请基于我提供的素材完成以下任务 1. 梳理chDB从立项到当前版本的整体开发时间线。 2. 提取每个阶段的关键技术决策并分析决策背后的原因。 3. 指出每个阶段遇到的主要技术难点和最终解决方案。 4. 总结这个过程中走弯路的地方如果能从素材中推断出 “如果重来一次会怎么做”请单独说明。 约束条件 - 所有结论必须从素材中推导不得补充素材之外的技术事实。 - 如果素材中有冲突信息请指出冲突并说明你采用了哪一方。 - 不要输出泛泛而谈的内容每个结论尽量关联具体的commit哈希或PR编号。 - 语气要像一位工程师在写项目复盘报告避免营销和夸大措辞。 产出格式要求 - 第一部分开发阶段总览用表格列出阶段、时间范围、核心目标 - 第二部分按阶段展开的关键决策记录 - 第三部分难点与解决过程 - 第四部分经验与教训如果素材中有据可查这个提示词看起来长但它每个部分都有明确目的。设置“嵌入式数据库开发者”角色是让AI自动切换到技术专家的语料体系减少泛泛的措辞。强调“从素材中推导”和“关联commit哈希”是为了抑制AI幻觉让它老老实实基于事实工作。要求表格和分部分结构则是为了让生成结果直接可用于文档沉淀省去二次整理。3.2 迭代式对话先框架后细节一次对话就拿到完美总结的情况很少见我现在的习惯是多轮迭代。第一轮只让DeepSeek产出一个阶段总览和大纲确认结构合理后再逐段深入。这样做的原因是开发历程里的因果关系经常是隐性的——某个阶段的设计决策可能要到很久以后才显示出影响AI如果一开始就把细节全部展开很容易只见树木不见森林。我第二轮通常这样追问“第一阶段里你提到了兼容层设计这部分的commit记录里有哪些反复重构请聚焦在SQLite事务语义和ClickHouse复制表的冲突上看看当时的解决思路是否经历了两轮以上调整。”这种带具体焦点的追问会让AI回到素材中寻找更深层的关联而不是复述已有结论。另外一个好用的追问方向是“请尝试用一个新贡献者的视角重新描述这个阶段。”这个要求会让AI主动补充“背景知识”和“入坑指引”输出内容反而更像一篇对社区有用的技术日志。开发历程总结给谁看直接决定了内容深浅。维护者自己看要的是决策回忆新贡献者看要的是背景和约定外部用户看要的是能力和边界。这个视角切换DeepSeek做得比我预期的好很多。3.3 让AI区分“事实”和“观点”这是我在反复迭代中总结出来的一个实用设计。开发历程总结里“事实”和“观点”必须清楚分开否则很容易把当时的情绪或者不成熟的判断当成经过验证的经验写进文档。我会在提示词里加一条“如果素材中出现评价性语言比如‘这个方案更优雅’‘性能提升明显需要量化’请标注为主观描述并尽量寻找量化证据找不到就注明‘仅为主观观点’。”比如chDB里有一个关于内存映射文件的决策当时团队内部争论过“映射整个文件”和“按需分页加载”两种方案。提交记录里既有性能测试的数字也有“后者实现更清爽”这样的个人偏好。AI如果能把数字和评价性语言分开呈现这个决策的参考价值就完全不同。这个约束并不复杂但效果很明显。生成出来的总结不会变成一篇“所有事情都很顺利”的流水账而是能让人看出哪些判断经过了验证、哪些还停留在直觉层面。4. 全流程实操从一堆散乱素材到一篇可发布的开发历程4.1 分步操作实录这里我记录一次比较典型的完整流程你可以直接照着走。第一步导出原始素材。在chDB仓库根目录执行mkdir -p /tmp/chdb_history/logs git log --all --dateshort --prettyformat:%h|%ad|%an|%s%n%b%n--- /tmp/chdb_history/logs/commits.txt然后把PR和issue从GitHub页面导出或复制下来按阶段放入对应文件夹。这一步粗糙一点没关系关键是保证内容完整。我自己甚至会把某些特别有代表性的评论单独存成一份highlights.md方便后续重点投喂。第二步编写阶段上下文文件。比如context.md里我会写阶段原型验证时间范围起始到某次commit 目标验证ClickHouse能否作为嵌入式引擎嵌入SQLite兼容层 核心问题 1. ClickHouse的列式存储是否支持进程内嵌入 2. SQLite的字节码执行模型能否桥接到ClickHouse的向量化执行 3. 最小可行产品的边界在哪里 最终产出一个可以在内存中运行简单查询的原型实例这个文件不需要长但它给AI提供了理解散乱commit的“结构性锚点”。第三步分阶段投喂并生成框架。按“阶段一、阶段二……”的顺序把每个阶段的context.md和对应日志依次发送给DeepSeek每次都要求它输出“本阶段目标、关键commit、技术决策、主要难点”四块内容。全部阶段处理完后再让AI合并成整体开发时间线。第四步追问和校验。对每个阶段逐条提问比如“你提到这个阶段引入了预聚合方案对应的commit是哪几条当时的验收标准是什么”通过这种方式逼迫AI回到素材里找证据把每个结论钉死在具体记录上。4.2 从粗糙时间线到高质量博文的三轮打磨第一轮AI生成的东西通常是一份“能看但不够深入”的草稿。真正让它变成一篇可以发布的长文需要三轮打磨。第一轮打磨补全因果链。我要求AI对每个阶段回答三个问题当时的约束是什么做了哪个选择后来因为什么而调整这一步会把流水账变成有逻辑的叙事。比如早期chDB支持的是固定列数超过一定阈值就回退到全表扫描这个限制在后来的版本中通过谓词下推给绕过了。如果没有因果链这段经历看起来就是“先受限再优化”补全因果之后就是“因为存储引擎的块迭代器不支持可中断操作早期只能全表扫后来给迭代器加了中断标志位才让过滤条件下推到数据块级别”。后者才是有价值的开发经验。第二轮打磨压缩同质内容放大高光细节。AI生成的总结有一个毛病就是每个阶段篇幅差不多显得平铺直叙。我会手动指示它“这个阶段的内容压缩为30%那个阶段的技术难点展开并补充细节。”比如chDB里兼容层的事务语义处理是极难的一件事AI第一版可能只给了两句话但实际开发中我们花了几个星期跟SQLite的锁模型打交道。这时候我会给它真正相关的commit和讨论内容让它围绕这一件事写足、写透。第三轮打磨加入人的视角。AI产出的文本即使逻辑再顺也缺少那种“我当时其实很担心这样会不会出问题”的真实感。第三轮我会让AI帮我保留技术骨架然后自己动手补几条带情绪的批注。这不是为了文采而是让阅读者知道这份记录是活人写的是带着不确定性和真实权衡写出来的。5. 避坑清单与常见问题排查5.1 提示词与上下文相关的问题及对策AI编造commit哈希怎么办。这是最容易出现的幻觉。解决方案是在提示词里反复强调“所有结论必须关联你实际收到的commit列表中的条目不许自己生成哈希找不到就写‘素材未提供’”。另外生成结果里的引用要抽查手动对照一下原始提交记录确认前后的描述和真实commit信息吻合。AI把不同版本的方案混在一起。我会要求它“先按时间顺序确认方案A存在于某时刻方案B存在于某时刻然后对比”。如果素材时间跨度很大最好明确告诉AI各位commit的先后关系避免它把早期的废弃方案跟后来的定稿方案并列讨论。上下文太长导致AI开始忘事。一次性塞几十万字素材不现实DeepSeek上下文有限内容过长会导致中间素材被忽略或者总结质量下降。最有效的办法是先按阶段分批处理再让AI合并。合并的时候不要把所有细节再次粘贴而是把每阶段的总结文本汇总并对有衔接关系的地方做局部追问。5.2 提示词之外的工程性问题除了AI本身的问题还有几个工程层面的细节值得说一说。素材命名混乱。如果一份文件里既有commit日志又有PR描述日期还不统一AI梳理时间线时会很痛苦。我最后选择在每个阶段文件夹里统一使用YYYY-MM-DD_描述.txt的命名方式并且每条记录都带原始日期。这一步看似琐碎却直接决定了后续总结的时间线准确性。不要忽视Review评论。Review评论里通常藏着“这个代码为什么不能这么写”的硬约束这些信息在commit里往往没有。我在chDB的兼容层阶段就有一条重要的约束——“SQLite的游标必须能回滚但ClickHouse的block流不支持任意位置seek”这句话最初是在一次PR Review的十几条评论里逐渐浮出来的单看任何一条commit都看不到全貌。所以素材准备阶段PR Review评论一定要完整导出。权限与隐私。如果项目不在公开仓库注意不要直接把内部讨论记录完整发给任何外部工具做好脱敏处理。涉及用户隐私、未公开的商业决策等信息要先行剔除只保留技术相关内容。开发历程总结要的是技术见解和经验教训不需要原样传抄那些敏感的完整讨论。5.3 一些零碎的实战心得用DeepSeek做chDB开发历程总结我前后尝试了三个版本期间也总结出一些零碎但很管用的心得。不要每次都从零开始发提示词。我会维护一个prompt_template.md文件把角色设定、任务描述、约束条件和输出格式都存下来每次只替换项目和阶段名称。这样一致性好生成质量也更稳定。给AI一个“没有素材就直说”的许可。开发历程肯定是残缺的总有那么几周没有写commit消息有些决策找不到记录。允许AI坦诚地标注“此阶段资料缺失无法推断具体过程”比让它硬着头皮编一段靠谱得多。最终生成的总结里明确标注了缺失信息的部分反而显得更真实可信。同一个总结任务变换几次问法结果能带来很多新灵感。比如请AI“以新贡献者视角”“以用户视角”“以竞品开发者视角”各跑一遍不同视角下的侧重完全不同。新贡献者视角会想知道代码该往哪个模块加、哪些代码是核心路径用户视角更关心边界行为和限制约束竞品开发者视角则可能会直接问“你们为什么要选这条技术路线你们的妥协在哪里”。把这些不同视角的产物叠在一起能自动发现很多之前没有意识到的盲点。6. 从“留档”到“传播”开发历程的下一步利用开发历程总结完成之后我推荐做三件事回流文档、生成社区版本、持续迭代。回流文档是最直接的收益。把AI生成的开发历程里“关键决策记录”“技术难点过程”这两部分整理后并入项目的docs/development.md或者ARCHITECTURE.md。新维护者装机、写代码前先读这份文档遇到“为什么这里有这个兼容层”“为什么这个接口不能并发调用”之类的问题时至少有一个自查的入口而不是每次发issue或者私信找维护者问。生成社区版本则是一个很有意思的场景。面向社区发布的开发历程不需要内部版的全部细节反而要更侧重“这个项目解决了什么问题”和“这个项目怎么使用”。我让DeepSeek基于完整总结生成一版适合公开发布的文字删掉比较敏感的早期争论细节把篇幅重心放在对外可见的功能演进和约束说明上。社区反馈的每一条“你们为什么不做X”的issue我都可以从开发历程里找到当时的决策背景来回复省去了很多重复解释的成本。这个开发历程总结不是一次性工作。代码库每周都有新commit新决策每两个月就有一轮。比较好的做法是设定一个固定节奏比如每个重要版本发布之后把新增的commit、PR、issue喂给之前的总结结果让AI做增量更新。因为基础框架已经有了增量更新比从头写一遍要快得多质量也更稳定。从我自身的体验来看让DeepSeek来总结chDB开发历程真正价值并不是“省了写文档的时间”而是它提供了一种外部的、结构清晰的眼睛能看到我自己因为太熟悉项目而忽略的关联和模式。开发者在写总结时很容易陷入“凡走过的都是必经之路”的惯性叙事AI则会根据素材里的冲突、反复和缺漏把那些被我遗忘的弯路重新摆到桌面上来。这也让整个项目的发展路径变得比记忆中的版本更立体、更接近它本来的样子。