直接打回去和 UI 设计不符就行了，不要沟通，再来几次不改就直接找他上级/你的上级反馈。

1. 这就是个快速成型的屎山，并且完全没法重构（重构不如重写快）
2. 完全 Vibe Coding 就只适合项目前中期快速试错，一旦项目复杂度上来了，就需要人大幅度介入和参与了，人和 LLM 的主次就反过来了，所以挑选一个合适的炸屎时间尤为重要。

股市的短期变动本就不反映真实情况，只反映“被引导的情绪”，懂行的人引导情绪割韭菜，不懂行的人被引导被割韭菜，是真是假重要吗？

这么快就开始美化记忆了？

基本费用都不会太低，不如咸鱼卖二手。

@mapleincode

1. 如果你的目标是项目写的更好，代码写的更好，那么你确实努力了，你的回报就是你的代码/项目写的很好了。
2. 如果你的目标是获得更好的回报，那么你确实没有努力，你没有主动去选择，你一直都是随波逐流。

另外，我说的责任，不是在某一件上的责任（锅）归谁，而是在一些关键节点，关键事情，你没做好的点在哪（没有选择跳槽、没有争取加薪，没有据理力争等等等等）

1. 很多时候，选择大于努力。
2. 不要被“假努力”欺骗了自己。
3. 在自省的时候把责任都推给别人对你自己的提升没有帮助。

可以说一个大概的方向：
1. 首先你让把 Agent 当成一个人，建设 Agent 的过程就是培养一个 Debug 助手的过程，可以先定义一些系统上下文，告知它要做什么，有哪些原则等（一开始可以简单点少一点，后面再慢慢调整）
2. 一开始要从上下文着手，假设你是这个助手，你要找这些问题，需要哪些上下文
3. 基于 2 去构建 tools / skills / mcp ，给你的助手装上各种「工具臂」
4. 123 做完了，你这个助手就基本成型了，后面就是慢慢的根据它的“表现”优化（上下文、工具之类的），但是一定要注意，不要过早优化，一开始给到 LLM 的上下文越 raw 越好，不要做太多的上下文调整，也不需要给太多的提示、规则，现在的 LLM 已经有足够的常识去应对这些问题，你重点是把你特有的上下文提供给它。

Codex 应该没问题，OpenAI 对于这种一般都很放开，之前还支持官方 Opencode ，目前除了 Anthropic 之外还没听过哪一家会因为这种使用被 Ban 的。

套现一部分，剩下的让利润奔跑。

Vibe Coding != AI 辅助编程

你就说这几年收的红包钱就好了，比如福建那地方一年的红包钱几万的都有。

同样的方式：
1. 先找到一个套自己喜欢的风格
2. 最好能找到一个差不多的竞品
3. 用 agent-browser / playwright / 直接截图的方式让 LLM 去抄一个并且形成样式规范
4. 基于 3 生成的再去微调

说白了就是先找一个好看的来抄之后再改，不要尝试去写文字 prompt ，尽可能让 agent 自己去「看」

我也觉得放 README 没什么意义，对于这种死猪不怕开水烫的惯犯，你打印出来贴他头上都没用。

用什么模型不影响使用 skills （本质上只是上下文+脚本），但是不同模型调用“工具”的能力是差别很大的，你可以使用 /skills 看看有哪些可用的 skill ，然后通过 /xxxx 显式调用看看

改革/改变是件很难很痛苦，需要很长时间的事情，你老板是通过这种方式把企业做起来的，他就会迷信这个依赖路径，直到公司倒闭或者他“被”痛定思痛（可能性不高）。
而对于你而言，有两种选择：
- run ，但是 run 很多时间解决不了这个问题，大多数公司都是这样，遇上企业文化好、且合作的人够专业的公司太难了。
- 尝试接受并且适应，不要无脑的用同一种模式去处理不同的需求，学会分级需求和分拆目标，用不同方式去处理不同的需求，另外要学会向上管理，要充分了解上面的人的习惯，学会怎么去应付，总的来说就是要学会怎么交付。