本帖最后由 student0618 于 2026-4-4 07:23 编辑
尝试只用开源工具vibe code计算化学建模小玩具全记录 (已完成) 2026 年 4 月
免责声明
• 使用LLM agent 存在一定风险，请自行负责。
0. 前言
假期找了一个小课题来练习，试一下只用开源工具去跑一遍最近很火的让LLM主导vibe code开发小玩具过程，看看需时及成本。
这次是教学方向的测试，只使用开源的工具。
0.1. 这篇想解答的问题
- 如果是一个只有课题、只有想法的人，没什么理论背景，能否只靠开源工具达到目的？
- 开源模型能力远远不及Top 5大模型，但实际上“能不能先将就用用”？
0.2. 因应测试目的，项目开展前设定了以下的限制及要求：
a. 给自己设的限制：
- 尽量让LLM决定不要手动改，当自己是一知半解的外行人 (虽然最后还是忍不住手动调整了些)。这边所说的决定很主要是指细节上的决定，例如输出什么格式的三维模型对计算化学社群更有用、图表放左边还是右边、数值用什么单位、字形用哪个等，而非大方向。让LLM作决定这点，是模拟外行人/学生。
- 因上述“使用开源模型”这点，不使用Top 5 模型，只用按量计算的openrouter 低成本小模型及opencode自带的免费模型。
b. 对LLM的要求：
- 验证文献来源！！！
- 如果有猜测的部分需在limitations明确列出
- 不要自行安装Dependencies，环境没的列出所需要的版本，让我自己安装。最近太多supply chain 问题很可怕。
实际上也不算0 开始vibe code 的，关键步骤我有说用哪个库来去做，一开始也提供了几个文献数据的连结。其他都让LLM主导，我只负责提供一开始的idea、给意见及测试反馈。
1. 目标开发的程序
- 实验性质，只敢说是是玩具，不敢说是工具。
- 想法是做一个按特定Condition生成某常见物质三维模型的工具。各种定义用现有文献资料、生成三维结构用现有的库。
- 由于重点不是成品的建模小玩具而是过程和心得，故不放github连结了。有兴趣的读者可以猜猜，不过私信我不会给的。
2. 计划
2.1. 两大milestone
v1 命令行工具
已完成 7+2个 phases
- 总耗时3 天
- 成本 60 USD
- token Input 36.3M / Output 1.7M / Cache Read 140.0M / Cache Write 1.3M
v2 图形介面工具
已完成 - v1+v2 累计成本160 USD
- Tokens Input 103.8M / Output 3.3M / Cache Read 284.8M / Cache Write 2.1M
2.2. 所用第三方Agent的开发工作流
使用的是Github上的一个给opencode用的markdown agent + slash command工作流。
看似很长，实际是自动跑的。到checkpoint会提示下一个指令。
开展项目的流程
1. new project (milestone) definition
2. 讨论内容
3. 计划milestone的目标
4. foundation research
5. 将一个milestone画分多个phase 并 建立roadmap
6. **详尽计划并实行每个phase
7. 所有phase 完成后验证milestone目标已完成并tag release
8. 开展下一个milestone
**一个Phase的流程
1. discuss
2. Research
3. Plan -> plan checking (-> revise plan -> check ...)
4. execute
5. verify -> debug -> verify 直到问题解决
6. UAT
3. 过程
3.1 v1 命令行工具
3.1.1 初始输入文件
• 部分文献连结
• 第一个prompt 的架构
- Provided the XXX libraries in current conda environment installed using @environment.yml.
- Derive a framework to do XXXX
- The final outcome will have A, B, C, D.
- This repo should have documentation X using tone Y for target audience Z.
3.1.2. 讨论出来的计划
1. Input validation
2. Condition mapping
3. Structure generation
4. Scoring and Ranking
5. Output
6. Documentation
7. Audit
后来加了的重要Bugfix phase，分别解决missing important data point问题及code scan找到严重影响速度的nested for-loop等问题。
v1 大部分时间及token花在调整生成图表整合文献数据的工作上。
3.1.3 测试/检查要点
• 文档Review citation 及verify links
• 完成后Scan codebase 及解决重要bug
• Scan code生成输入示例cli后会跑什么的流程图，协助理解程序设计概念
3.2. v2 图形介面工具
3.2.1. v2 原始prompt
- # Dependency
- This is only done after the release of v1
- # v2 requirements
- Create lightweight, standalone, cross-platform executable GUI application of XXX (windows and linux 64 bit)
- The GUI features an all-in-one interface with the following:
- 1. Feature A, that the user can do action X
- 2. textbox to input options
- 3. info window of info when user do action X, with necessary citation
- 4. button to generate 3D structure after user action X
- 5. progress bar to show the generation progress
- 6. 3D viewer of the generated structures, show one at a time to save resource. simple view of stick/ball and stick and dashed lines of hydrogen bonds
- 7. option to save the plot/3D structure/export data/image of 3D scene to file
- Notes:
- a. Cap the number of molecules for the generation
- b. Provide minimal explanation to each option (one `i` or `?` next to everything for the user to check, in addition to markdown user manual. Human will provide the pdf manual with screenshot based on the markdown manual)
- c. Check the license of the libraries, and suggest whether is ok to distribute as a standalone executable with the current chosen license.
3.2.2. 讨论出来的计划
8. GUI infrastructure and core input
9. Interactive [feature XXX]
10. 3D molecular viewer
11. Save, export, and in-app information
12. v2 Documentation update
13. Packaging and distribution
3.2.3. v2备注
• 3D 显示介面花很多时间调整和debug
• Phase 9 debug GUI 时顺便解决了v1的一个作图的小bug
3.3. 其他备注
• 小模型的Context window较小 (约200K token)，用目前的orchestrator - subagent 工作流可有效管理每个session的context window，通常orchestrator的context用到 50% (100K tokens) 就可以进入下一个session，每个sub-agent大部分都用少于50%。
• debug如果直接跑会用很多context较难处理，经常要压缩。开专门的debug session用debug subagent+debug workflow较理想。
• Fake reference还是很严重，要重复要求验证，也紧记必需全部人工验证一遍所有reference和link。
4. 小结
以上分享了一次Vibe code建模GUI小玩具的经验，就当是一个记录。
这练习于我有以下启发：
• 教育方向，未来那些找工具介绍的课堂作业，其实都可以改作写工具的作业让学生学到更多了。
• 研究方向：编程门槛大幅降低后，“有想法，但没工具很难处理”这情况不久后应越来越少了。
5. Q & A
Q: 这课题怎么想的？
A: 随便打开一本书抽课题抽出来的。
Q: 有什么science以外的个人感想？
A: 很多，例如
- 体会到reject/approve/PUA LLM工作。无论大模型还是小模型都有操作要reject的，不过小模型作高风险操作的机会更多。
- LLM帮忙写的motivation很积极乐观，其实这不是我最初的motivation喔
- 也学会不少写程序的思路。
- 还有我都Deny了rm指令，LLM还浪费token碰钉子......
Q: bugfix 最实用的提示词
A: debug几轮解决不到的问题，说一句 very disappointing 就立即解决了
| 
发表于 Post on 2026-4-2 23:21:41
收藏 Add to favorites
楼主 Author