Yao
Web developer, I like reading and explore the internet, so I have collected queit a few notes in my blog.
发现似乎今年都没有写什么长的东西,今天强迫自己坐下来写一点东西。
最近耽搁了Elick的开发,因为忙上了开发新的玩意儿,主要是两个新的东西,一个是有用的,帮助我自己提升英文写作能力的工具,算是我开发的“AI辅助学习工具系列”的第二个工具,初步体验效果还挺不错的,等后续完善后会推出。
另外一个是好玩的,是用DeepSeek来辅助我小说创作的一个工具。
两者实际上最开始是同一个项目,我在写英文写作工具的时候,尝试了一下DeepSeek能不能写小说,然后发现效果还挺不错的,于是干脆就又同时写了小说辅助创作的工具。
如果把写作理解为是一种拼图游戏,那么人物,故事,场景,事件就是一个个拼图,创作就是:
- 首先“生产”一个个拼图
- 然后把它们以合适的方式拼凑在一起,组成一个完整的故事
而DeepSeek能够在生产拼图这个流程中给出有效的帮助。比如在写作时,当不确定某个物品或者某个场景应该如何描述,或者是对当前描述不满意,这时候我会选取这段物品的描述,然后让AI按照设置重新生成多个不同版本的描述,然后选中我认为合适的版本。如果还不符合要求,就继续按照新的反馈生成新的多个不同的版本,直到最后生成自己认为合适的版本。
但是在步骤2中DeepSeek还暂时给不了太大的帮助。
为什么DeepSeek无法完成完整故事的创作?
一方面是因为大模型本身的缺陷,这个这里我们不作讨论;另一方面,我觉得也许是在生成完整故事时需要的上下文工程要多得多。
我们通常在使用AI生成故事时,只会给出一段非常简单的要求让它生成一个对应的故事,比如:
“请帮助我生成一段小蝌蚪找妈妈的故事”
而这对于创建一个完整的故事来说实际上是完全不足的,它留下来的空白太大了,比如从剧情本身来说,没有指出整个故事的具体流程,小蝌蚪的性格是什么,为什么要找妈妈等等;
然后也没有指明叙述的视角,这个故事是否从小蝌蚪的第一视角展开?还是说使用上帝视角进行叙述?是否需要提供小蝌蚪妈妈的视角?
当我们给出足够的上下文设置,通过合适的prompt来进行设置时,也许就能够生成一段足够完整可用的故事;具体应该如何设置我还在探索中,需要我后续自己进行创作和使用后来确定。
这个工具如何帮助创作
当前我使用这个工具的流程大概是这样:
比如以某段剧情举例,整段剧情都会是由我自己构思的,我会想好这段剧情要发生些什么,要描述什么内容,要推进什么剧情,基于以上完成一段故事大纲,然后创建一个事件卡片,在这个事件卡片里,我会让AI按照顺序生成整个具体的故事流程和参与该故事的人物(主要没有进行对应设置的话),这个流程类似时间线,它会以顺序的方式指明每一个叙述点要描述什么内容,比如:
- 叙述A偷了商店里的零食
- 叙述他初次的惊慌,和没有被发现后的庆幸
- 写A再次进行偷窃。
生成以上时间线后,我会进行初步检查,确保整个人物侧写和故事流程是正确的,如果不正确我会进行修改。
然后调整设定的叙述风格(这个很重要),最后根据这段剧情的上下文(比如之前发生了怎样的情节)进行生成这段剧情的初稿。
这个初稿通常会非常粗糙,只是一个故事的轮廓,还需要我自己进行“二度加工”。可以这么说,二度加工本质上才是我写作的真正开端,前面几个步骤更像是在做准备工作。
在二度加工中,我会像以上写小说一样进行创作,只有在不确定如何描述某个物品或场景时,我会选取这段物品或场景的描述,然后让AI按照设置重新生成多个版本的描述,然后选择里面可用的内容。
相比之前需要从0到1来创作整个故事,现在可以让AI生成这个1,然后自己再慢慢完善到60以上,看上去好像AI并没有做什么,但经历过创作的人都知道,从0到1这个过程最困难的,度过这个阶段后创作会舒服很多。
参与使用
这个项目还十分之不成熟,不过如果有人想使用的话可以点击网站尝试,所有数据都保存在本地,不会泄露,但是需要注意的是,因为还处于开发阶段,可能十分不稳定,当你完成创作后最好将内容及时保存在其它地方,避免因为更新改动而丢失。
如果你有任何反馈,可以尝试在以下仓库中提issue,或者是直接发邮箱给我。


Yao
Web developer, I like reading and explore the internet, so I have collected queit a few notes in my blog.
2025.11.16更新
我错了,大错特错!在用了一个礼拜后发现Claude Code好用太多了,不是代码质量上更强,而是在工程实践和开发体验上。我现在的使用流程是把augment和codex都作为Cluade Code的一个mcp,然后在需要进行代码方面的处理时进行调用,这样又能利用Claude Code的优势,也能利用ACMCP和Codex来提高Claude Code的编程质量(以及节省token)。
之前一直在用Augment Code(下面简称AC),使用体验非常好,甚至现在在初步体验过Claude Code后,我是还认为Augment可能才是现在编程质量最高的Vibe Coding工具,只是因为在更换价格策略后,用AC非常不划算,,所以就想尝试一下Claude Code。
UI/UX
单纯从UI/UX上来说,可能AC会更适合一般人使用,因为它仍然保留了类似ChatGPT的对话界面,一般人更容易理解如何使用,但缺点是每次打开时都需要打开IDE来使用。
而CC运行在终端,所有交互都通过控制台输入来进行,这个对程序员来说是更舒服和自然的交互方式。
编程能力
因为还只是刚刚开通,暂时还没有深入的使用,所以并不能下出准确的结论,这里主要谈的是之前使用AC的经验(在AC中我使用的基本也是Claude的Sonnet模型)。
因为在Claude Code的Pro中计划能够使用的最好模型是Sonnet 4.5,所以Sonnet 4.5的能力基本就代表了CC Pro的上限,所以如果Sonnet无法解决一个问题时,那基本就没招了。
而在AC中如果Sonnet无法解决,还可以切换到GPT-5。实际上我已经经历过几次这样的情况,几次都是问题过于复杂,Sonnet 4.5无法解决,这时候切换到GPT-5就解决了。
题外话:因为有人把AC的一个重要工具Augment Context Engine给逆向出来,做成了一个ACEMCP,所以在CC中也能够使用到AC中强大的上下文处理功能,所以理论上来说,CC应该不会逊色于前者。
价格和使用量
AC在未修改价格策略之前,性价比非常高,20$/150次使用次数(还是130?忘记了),而如果你使用cunzhi或者MCP-feedback-enhanced这样的工具,将每次对话的次数都延长到最大,一个月每天二十四小时用都用不完,我一个月除了睡觉几乎一天都在高强度使用,但使用的次数还不到50次。
这样以次数,而不是以使用的token来计费的策略对用户非常友好,但是对AC就没那么友好了,根据AC自己公布的消息,有的用户只支付了20$,但是使用的成本却超过了上万$,AC承担不起这样的成本,不得不修改价格策略。
但是问题是现在的策略相比之前又太过严苛,同样是20$,之前是一个月用不完,现在是一天就用完了······这里差的数量级对用户来说真多太不友好了,这导致几乎不会再有用户考虑开通AC的Pro Plan,因为实在太不经用了,要用至少得开Max才行。
但问题是,相比AC Pro的每月30$,却几乎只能支持高强度使用1-2天,而CC只需要20$就能够提供近似的编程质量,而且足够一个月使用,即使不足够,CC还能够配置使用其它模型,比如便宜得多的GLM或Kimi。
即使AC编程的质量确实比CC要高,但是绝对不足以填平这里价格带来的沟壑。考虑到AC不像CC背后有Anthropic撑腰,可以不需要太顾虑大模型调用的成本,这次价格策略的调整恐怕也是不得不做出的选择。
最具性价比和质量的Vibe Coding方案
综上,如果现在想要体验Vibe Coding,我觉得最具性价比和质量的Vibe Coding方案可能是:
- Claude Code Pro。主力coding工具,20$每月。
- ChatGTP Pro。用于CC解决不了的疑难问题,20$每月。
- ACEMCP。利用AC的大的上下文处理功能,能够非常有效地提高CC的编程质量,而且是免费的,你只需要有一个AC的试用账号即可,但是可能配置起来比较复杂。