计算化学公社

标题: 尝试只用开源工具vibe code计算化学建模小玩具全记录 (已完成) [打印本页]

作者
Author:
student0618    时间: 2026-4-2 23:21
标题: 尝试只用开源工具vibe code计算化学建模小玩具全记录 (已完成)
本帖最后由 student0618 于 2026-4-4 07:23 编辑

尝试只用开源工具vibe code计算化学建模小玩具全记录
(已完成)
2026 年 4 月


免责声明
• 使用LLM agent 存在一定风险,请自行负责。


0. 前言
假期找了一个小课题来练习,试一下只用开源工具去跑一遍最近很火的让LLM主导vibe code开发小玩具过程,看看需时及成本。
这次是教学方向的测试,只使用开源的工具。

0.1. 这篇想解答的问题

0.2. 因应测试目的,项目开展前设定了以下的限制及要求:

a. 给自己设的限制:

b. 对LLM的要求:

实际上也不算0 开始vibe code 的,关键步骤我有说用哪个库来去做,一开始也提供了几个文献数据的连结。其他都让LLM主导,我只负责提供一开始的idea、给意见及测试反馈。

1. 目标开发的程序


2. 计划
2.1. 两大milestone
v1 命令行工具
已完成 7+2个 phases

v2 图形介面工具
已完成

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 的架构
  1. Provided the XXX libraries in current conda environment installed using @environment.yml.

  2. Derive a framework to do XXXX

  3. The final outcome will have A, B, C, D.

  4. 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
  1. # Dependency
  2. This is only done after the release of v1

  3. # v2 requirements
  4. Create lightweight, standalone, cross-platform executable GUI application of XXX (windows and linux 64 bit)

  5. The GUI features an all-in-one interface with the following:
  6. 1. Feature A, that the user can do action X
  7. 2. textbox to input options
  8. 3. info window of info when user do action X, with necessary citation
  9. 4. button to generate 3D structure after user action X
  10. 5. progress bar to show the generation progress
  11. 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
  12. 7. option to save the plot/3D structure/export data/image of 3D scene to file

  13. Notes:
  14. a. Cap the number of molecules for the generation
  15. 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)
  16. 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: 很多,例如

Q: bugfix 最实用的提示词
A: debug几轮解决不到的问题,说一句 very disappointing 就立即解决了













作者
Author:
王二葛    时间: 2026-4-3 18:04
你那两条限制给我看乐了,都不用往后面读了

- 「尽量让LLM决定不要手动改」,你才是项目的核心,是你的想法主导项目,你自己都不清楚要干什么那 vibe code 出来也是垃圾
- 「不使用Top 5 模型」,莫名其妙不用新模型,放着聪明 agent 不用,非要去自以为是地 PUA 一个不太灵光的学生

你要觉得贵就开个会员用 claude, codex, antigravity,最新的模型站起来蹬
作者
Author:
wal    时间: 2026-4-3 18:09
王二葛 发表于 2026-4-3 18:04
你那两条限制给我看乐了,都不用往后面读了

- 「尽量让LLM决定不要手动改」,你才是项目的核心,是你的 ...

不用top5也没啥吧,Claude GPT Gemini的各种coding模型包圆前五感觉没啥问题,撇开这些还有kimi,glm之类的能用啊,写个小东西感觉问题不大
作者
Author:
student0618    时间: 2026-4-3 18:28
本帖最后由 student0618 于 2026-4-3 22:26 编辑
王二葛 发表于 2026-4-3 18:04
你那两条限制给我看乐了,都不用往后面读了

- 「尽量让LLM决定不要手动改」,你才是项目的核心,是你的 ...

非常感谢阁下的建议。抱歉我发现目的没写清楚,刚刚在正文补回试用开源工具这点。

标题也已经因应原文带来的误会,更正为“尝试只用开源工具 vibe code”这一点,盼可厘清这篇的真正目的。

这次其实是教学方向的测试,尽量只用开源的工具,去探索一下,如果是只对课题一知半解的人 (例如外行人或学生) 可以如何、小模型对这情况“能不能用”。只有课题、只有想法的人,能否用只靠开源工具达到目的?这边所说的决定是指细节上的决定,例如图表放左边还是右边、数值用什么单位、字形用哪个等,而非大方向。
让LLM作决定这点,是模拟外行人/学生。

我有大模型订阅的,配额每次刷新都很快用完。Top 5 的 Claude GPT Gemini grok (我心目中目前top 5第一第二位都是Claude) 基本有新版本都会立即试用,非常认同您所说top 5模型它们的强大。
用它们的话2-3天大概都完成了,不过订阅配额有限,而且写这个小玩具测的是开源工具。
我知道gpt很爱git revert但通常写代码一次就get it done,Claude作agent很好用,gemini很常rate limit但ppt设计很优雅,grok整理资料很顺。

再补充一点,其实我所用的开源开发Workflow本来是有人给claude code写的vibe coding专用轻量agent skill/slash command,cc版本有47K 个star。后来有人把它改为opencode适用的工具,目前也600多个star了。当然,我明白这workflow是否好用也因人而异的。我用这workflow跑过大模型,也跑过如一楼说的开源小模型。







欢迎光临 计算化学公社 (http://bbs.keinsci.com/) Powered by Discuz! X3.3