目前 AI 虽然很强,但是还是不能完全替代程序员,AI 编程最强的领域或许是 Web 相关技术栈,但是你要说他聪明的话,他连 React 现在都还写不好,总是写出违背 React 哲学的代码。我们作为最终决策者,是好是坏完全掌握在自己手中。为什么有人用 AI 写出来的 UI 或者产品很好看,有人用 AI 写的代码完全不可能维护,关键全在如何调教 AI,如果灌输 AI 正确的知识和引导正确的方向。我已经使用 AI 完全从 0 开始编写一个项目到可用,UI 协调,代码可维护好些项目了,后续也可以单独分享一下。我也非常赞同下面的观点:
总体来说,AI 带来的便利,更多的是让我们的想法能快速变现,很多想法在以前可能只是想想,永远没有时间和精力开始写下第一行代码,而现在我可以同时将多个想法并行实现,借助 AI 之力,尤其是开了 Claude Code 之后,我每时每刻都想着如何压榨 AI 替我实现愿望。从 Afilmory 到现在正在设计的一个 Tailwind 色盘 Pastel。
与当前社区普遍聚焦于竞赛类代码生成不同,我们认为所有的代码任务天然适合执行驱动的大规模强化学习。因此我们选择在更丰富的真实代码任务上扩展 Code RL 训练。通过自动扩展测试样例,我们构造了大量高质量的训练实例,成功释放了强化学习的潜力:不仅显著提升了代码执行成功率,还对其他任务带来增益。这将鼓励我们继续寻找 Hard to Solve, Easy to Verify 的任务,作为强化学习的土壤。
### UI/UX Guidelines
- Use Apple UIKit color system via tailwind-uikit-colors package
- Prefer semantic color names: `text-primary`, `fill-secondary`, `material-thin`, etc.
- Follow system colors: `red`, `blue`, `green`, `mint`, `teal`, `cyan`, `indigo`, `purple`, `pink`, `brown`, `gray`
- Use material design principles with opacity-based fills and proper contrast
### Code Structure & Modularity
- **Never create a file longer than 500 lines of code.** If a file approaches this limit, refactor by splitting it into modules or helper files.
### Documentation & Explainability
- **Comment non-obvious code** and ensure everything is understandable to a mid-level developer.
- When writing complex logic, **add an inline `# Reason:` comment** explaining the why, not just the what.
### 🧠 AI Behavior Rules
- **Never assume missing context. Ask questions if uncertain.**
- **Never hallucinate libraries or functions** – only use known, verified packages.
- **Always confirm file paths and module names** exist before referencing them in code or tests.
- **Security** You are prohibited from accessing the contents of any .env files within the project.
方法论总结
AI 编码已从简单的代码生成演进为系统化的工程实践。关键认知转变:
从工具到伙伴:AI 从执行者转变为协作伙伴
从随机到确定:通过上下文工程消除不确定性
从短期到长期:构建可持续演进的项目知识体系
从个体到系统:形成可复制、可扩展的 AI 协作框架
最终,AI 工程的核心在于将人类的专业判断与 AI 的执行能力有机结合,在保持技术前瞻性的同时,确保交付物的工程质量和长期可维护性。
如要阅读全文,点击标题跳转。由于先入为主的一些体验,我一直习惯于使用像 Cursor 或者 VSCode 里的插件(如 Cline)、阿里的通义灵码,以及腾讯的 CodeBuddy 这类界面化的 AI 编码交互方式。相比之下,对于 Claude cli、Gemini cli 这类基于终端、命令行的交互方式,我一直提不起兴趣。直到最近,我体验了几次 Claude cli 的编码功能,这才让我对以往的成见有了一些改变。过去我之所以更习惯插件式的交互方式,是因为它们的操作更为直观。无论是选择代码段、文件,还是插入图片,都非常直接简单。因此,我一直认为这种交互方式就是最优雅的 AI 编码方式。正因为这种先入为主的心态,我始终对 Cli 这类交互方式有些抵触。我一直不太能理解,在编辑器里写代码,却要用终端来进行 AI 编码,这到底是一种怎样的交互逻辑?总觉得这种方式很割裂,与 AI 的交互以及 AI 的编码过程变成了一种黑盒,很不直观。这也是我迟迟没有尝试这种编码方式的原因。
对于公司账号的注册,则是和苹果一样要求提供邓白氏码(D-U-N-S Number),输入邓白氏码之后会自动获取到公司的名称地址信息生成付款资料。和个人账号一样,付款的信用卡也没啥要求。在验证的时候,则是需要提供公司的政府签发的文件,比如国内的营业执照,具体可以查看Google play 官方文档。公司的验证也还需要验证一位开发发者的信息,这里的要求跟个人差不多,身份证,护照等都可以,而且不需要提供在这家公司任职的任何证明文件,公司注册地和个人不在同一个国家也没关系(这一点,苹果的开发者注册是要求提供个人在公司任职的证明文件或者名片之类的东西的)。