Toolchain

工具链选择的原则：用领先模型，但不要把工具当答案

会议对工具的态度很清醒：领先模型值得花钱，因为 Token 远低于人力成本；但真正决定质量的是组件库、脚手架、设计参考、测试闭环和团队规范。

Claude CodeCodexKimiGeminiStitchGo ZeroRust

Models

模型选择：优先领先模型，持续重新评估

模型能力变化很快，旧经验会过期。

会议里明确建议尽量使用领先模型。一个中级工程师的人力成本远高于模型订阅和 Token。

Kimi 适合大面研究和设计方向铺开，Gemini 更适合追求事实细节，Codex/Claude Code 各自适合不同编码工作流。

三个月可能就是模型两代变化。团队应定期分享模型跨过哪些门槛，而不是固守半年前的判断。

Frontend

前端难点不是能不能生成页面，而是审美、状态、回归和多端一致性。

Ant Design 等成熟组件库能把基础控件质量稳定下来，自有业务组件则减少重复生成和反复改坏。

早期验证可用 GPT 图像、Stitch、Dribbble/Behance 参考稿和站点 CSS 总结来形成风格约束。

模型对视觉理解有限。布局、长文本、移动端、状态切换和细节一致性仍需要人工检查。

Backend

后端可见性差，更依赖分层和稳定流程。

把数据层、算法层和业务逻辑层分开，围绕关键流程节点推进，而不是让 Agent 在整套系统里自由游走。

Go Zero、现有优秀框架源码和旧项目都可以作为脚手架参考。让 AI 读懂关键节点，再迁移到新项目。

会议提到 Rust 等高性能语言可能随着模型能力提升变得更可用。语言选择不只看人会不会，也看模型能否稳定产出。

Trend

当模型会写代码后，真正昂贵的是表达不清和概念混乱。

变量、模块、角色、业务对象和行业术语越混乱，模型越容易生成貌似合理但方向错误的方案。

模型对标准后端、常见业务和公开知识领域会持续变强，冷启动脚手架会越来越接近最佳实践。

当领域知识未被大规模写入模型，或任务本身没有标准答案，专家判断和实验反馈仍不可替代。