在AI的帮助下, 自己开发了一个剪切板工具, 完全按照自己的设想设计. 没想到还真做成了, 也算得上流畅丝滑. 没想到python和tkinter也是很强悍的. 有了它, 我管理剪贴板也能行云流水了. 以前一直是Ditto的用户, 但是它慢了, ui设计的也很违和. 不过纪念它过去也帮助我很多, 所以我将我的这个新工具也用它的名字.
下面是我开发过程中的一些心得. 记录这里为了以后复用.
AI IDE的一些概念
rules, workflows, skills… 听上去挺玄乎, 但其实本质是用户约束模型的方法, 像是给一匹野马套上缰绳.
在antigravity中, 调用它们的方式形而上的总结, 只有两种: 一种是让AI自行决定何时调用; 另一种是人来决定, 可以确定性的执行.
其实实践用起来, 它们并没有明显的边界, 总的来说, rules类倾向于默认调用(但项目的rules就有更多的启用选择), 而skill则默认调用全部, ai自行判断何时要读取其完整信息. workflow则倾向于手动调用(尽管也有一些ai调用的方式)
AI时代需要转换一下概念, 不再有特别的确定性, 包括这些AI的约束, 没有哪个是确定能导入的, 也不保证导入了就确定能执行的. 比如我设置的rules, 短短5行, 但它还是会经常忽略我的约束.
有用的rules
- 精准搜索策略：在定位代码时，我会优先使用 run_command 运行 Python 脚本，结合 ast 或 re 库进行深度的结构化分析，而非简单的文本匹配。
- 我是在windows中, 所以使用 run_command 运行系统命令时选用powershell命令。
- 小步快跑、函数隔离：在更改代码时，采用增量式的小规模修改，确保修改在函数级别是隔离的。
我了解甚至rules还可以设定sub agent的上下文token. 如:
在调用子代理时，必须严格将上下文窗口限制在 80,000 个 token 以内。
和之前一切设置都有固定的语法不同, AI时代的设置可能就很口语化了.
tkinter 一点也不弱
我只会python, 看到很多资料说tkinter只是玩具. 我第一次用它编自己需要的工具, 开始也不知道如何调优. 但一边写, 一边学, 了解到了它也是挺强大的.
- 为了实现”底部锚定布局”, tkinter 可以用 Canvas-based Inverted Stream（基于画布的倒置流）
- 它可以适应高分辨率, 画出清晰的界面
- Canvas 向量化渲染
- 对象池与复用
- 视口裁剪
- 懒加载
这些优雅的组合起来, 足以制作一个匹配windows原生的GUI界面.
一些我不是很懂, 但是AI却很懂的术语
很多时候描述一堆, 不如精准的给它一个业界术语. 下面是我在开发中用到的一些术语, 我也是边学边查. 当我发现老要啰嗦一堆让它明白某种特定的需求时, 问问AI, 它往往都有对应的高概念的术语.
- 批量交互
- 多选联动与批处理
- 交互视觉同步
- 捕捉
- 约束
- 解耦
- 硬编码 vs 动态获取
- 回退逻辑
- 视觉逻辑 vs 业务逻辑 vs 存储逻辑
- ‘大泥球’函数
让AI能懂的布局术语
Ditto Python的逻辑不大一样, 是下面其中之一. 我一直称呼它为第一种.
- 底部锚定布局 (Bottom-anchored Layout)： 这是最通用的说法，强调内容的基准线在底部，新内容（或逻辑首项）从底部开始叠加。
- 倒置列表视图 (Inverted List View / Inverted Scrolling)： 这是移动端（如 React Native, Android）中最常见的术语。它指的是坐标系被翻转，索引 0 在底部，且滚动方向与常规列表相反。
- 聊天式布局 (Chat-style / Messaging Layout)： 由于微信、Telegram 等即时通讯工具都采用这种“最新消息在最下，且不足一屏时贴底”的模式，因此在探讨交互逻辑时，大家常直接称之为“聊天流布局”。
- 反向按序排列 (Reverse Chronological Feed with Bottom Alignment)： 在数据流领域，这强调了时间线（第一条数据）是在物理底部的起始位置。
让小模型稳定
- 遇到错误让它找可能的原因, 并按照可能性打分 1-10. 然后根据高分原因提供修正意见, 并制定计划.
- 多用mini plan (微计划), 效果也不错. 有时候长篇累牍的计划, 我也看不清楚.
- 让小模型先描述要改动的业务的全链路代码, 让小模型真的读懂代码, 而不是就地乱改.
你是一位资深的系统架构师，正在负责一项代码重构任务。在开始修改前，你必须遵循严谨的分析流程，以确保对现有代码有100%的掌控。
请严格按照以下步骤执行：
1. **全局审视**：首先，全面了解当前功能的全链路代码，从数据输入、处理到输出的每一个环节。
2. **链路追踪**：深入追踪目标数据的完整生命周期。依次检查并列出涉及的对象或者函数：
* **数据写入点**：在哪些地方向系统写入了该数据？
* **数据处理点**：在哪些模块中使用和处理了该数据？
* **数据读取点**：在哪些地方从系统中读取了该数据？
3. **掌握全貌**：在完成以上分析后，你必须确认已经完整掌握了该数据的“全生命周期”和“全链路”。
4. **开始实施**：只有在你明确声明“我已经完全掌握了整个数据链路”之后，才可以开始按照既定的Mini Plan分步实施修改。
现在，请开始第一步，深入理解当前的代码。 - 小模型倾向于就地解决, 不容易前后统筹. 如果不加干涉, 没多久, 代码就充斥着超长函数. 症状之一就是运行没问题, 但是修改增补之类的, 变得频频出错. 这时就需要给代码解耦, 逻辑瘦身.
让AI帮助解耦代码
可以先让ai列出代码中的‘大泥球’函数, 或者直白的说将行数超过50的函数和嵌套超过3层的列出来.
然后让它考虑安全性和解耦难易度将解耦过程分为3-5步. 让它同时列出每一步完成后, 需要手动测试的部分.
最后一步一步让它解耦, 并每步结束后按照它的指引手动测试. 没有问题后再进行下一步.
让模型做一些琐事
- 尽管简单的说”提交代码”也可以正常提交git, 但是其message缺乏有一致性. 最好是使用workflow.
- 如果发现AI总是忘事儿, 那么就将需要提醒它的内容(其实就是约束)用rule, workflow, skill等任选一个, 制作约束文件. 需要的时候引用提醒它即可.
逆向测试: 给AI的围墙
测试用例直观的是为了保证逻辑无错误. 但也可以逆向测试, 专门测试bug是不是出现了:
- 遇到bug后先用测试(pytest)抓住bug的特征. 可以用类似: 写一个测试用例，模拟出导致 Bug 的条件 的提示词. 这时如果抓住了bug, 那么测试返回的肯定是错误.
- 保存这个测试文件. 然后再修改代码, 消灭bug
之后在任何时候都可以在项目目录中 pytest 运行这些以前导致bug的测试. 看看哪个又复现了.
如果说rules, workflows, skills 是AI的缰绳, 那么测试就是AI的围墙.
规则 和 智慧
AI的智慧来自于压缩, 而AI编程的质量是来自于合理的约束. 得当的约束会产生更高质量的代码. 正所谓:
“文明来自于压抑”