国产的性价比是真的，但是能被 rk 香哭，说明他并不适合 hhkb 或者并不适合静电容键盘

trae 在收费前，这东西就是排队王，收费后至少是能用了。
他的卖点就是比 cursor 便宜，另外用反馈工具的话，trae 的 tool call 调用次数也比 cursor 多，我数过好像是 36 次。
另外 gemini cli 非常好，就是容易用着用着退回到 flash

计算器用多了，口算能力变弱了又如何呢。ai 让你从细节中解放出来，把精力更多地集中在更高的层面，比如架构/产品，这难道不是好事

@tyqing
同样的问题，不过我这里不知道为什么开 tun 会代理失效。但我找到了另一个方法，用 proxifier 指定 node.exe 走 v2 的 http 代理端口过授权，然后就不需要 proxifier 了，之后只需要 set http_proxy 那两句就可以了

@icy37785 框架的抽象可不只是为了写起来方便，可读性/可维护性更重要。原生糊多就是一滩，根本维护不了，多少上下文都不够造的。


虽然 vue3 不再提渐进式框架的事情了，其实依然是可以裸写的，配和 type="module"以及 idea 系的编辑器在字符串也可以提供 html 语法高亮，写个 demo 什么的其实看起来还行，写出来就像这样
<div id="app"></div>
<script type="module">
import { createApp, computed } from 'https://unpkg.com/vue@3/dist/vue.esm-browser.js'

// import HelloWorld from "./HelloWorld.js"
const HelloWorld = {
props: { user: String },
setup(props) {
const text = computed(() => `Hello ${props.user}!`)
return { text }
},
template: `
<h1>{{ text }}</h1>

<component is="style">
h1 { color: red; }
</component>
`
}

createApp({
components: { HelloWorld },
template: `<HelloWorld user="Vue"/>`
}).mount('#app')
</script>

我猜是针对反馈工具吧，说起来反馈工具真好用，再也不怕单次请求的工作量不饱和了。

ai 从 0 开始画个页面，美观程度到是不错。
要说擅长前端那真不太行，让 ai 让改交互/样式细节很容易打转绕圈出不来。
其中关键问题就像楼上遇到的那样，交互/图像有问题又不报错的，而且基于 html+css 结构(或者类似结构)的代码和实际呈现的对应没法保证直观，改前端就像是对着代码猜效果。
ai 还是适合改独立性强的东西，容易解耦分出来的东西，特别是各类小的工具方法，而前端，组件化的再好也是糊在一块的。

社区版/webstorm 用来做一些确认全局搜索/替换/git 之类的工作，钱续费给 ai

@maladaxia 可以的，甚至用批处理实现脚本都行（反正都是让 ai 写，不过批处理写中文好像有点问题）。
不过，我是 trae 和 cursor 都用的。两者有点差异，比如 cursor 可以直接读我的输入，直接中止脚本就可以了，trae 得把输入的内容再打印（或者说从标准输出流输出出来）出来。
顺便我发现 trae 给了 36 次的 tool call ，这样倒是不用担心 trae agent 不够强的问题了

关于 rule ，我是加了这么一行

每当完成用户本轮会话的所有任务后，调用反馈工具<code>运行反馈工具</code>并根据反馈完成修改。注意修改全部完成之后继续调用反馈工具。总之永远不要主动结束会话。

前些天刷到一个视频也是干这个的，我认为没有必要开一个 mcp 服务，特别是我不大用 py 。
其实只需要用你熟悉的语言写一个脚本，内容也很简单，等待用户输入，打印输入内容，没了。然后通过 rule 等方式提示 cursor 或者其他 ai 编程工具执行完任务后反复调用这个脚本就好了

@SachinBeyond 区域在设置搜 region ，选一个中国以外的就可以了吧

一个晚上用掉一半？怎么会用掉这么多的，是不是每次修改的问题太小了？其实可以每次聊天提多个问题让它一起修来节省次数。
另外关于 thinking ，其实可以试试不开，然后添加一个 always type 的 cursor rules 让模型进行 step-by-step 的思考，比如这是我的
“任何问题都应该先分析问题,逐步思考,最后再做出行动

若问题复杂,还应当简要的写出思考过程,思考过程可以写在<think></think>标签内”

ai 时代了，电子版都不一定要留了，先问 ai ，找不到再保留纸质版本

除非是个目标明确的小脚本，不然先写测试，或者说先写文档整理思路，生成测试，然后让 ai 写完跑测试，以及注意别让 ai 修 bug 的时候改测试内容

本来想说迷你主机，不过既然都在说迷你主机，那我说点不一样的吧。modt ，或者说自己组个核显 itx ，虽然说优点大概就只有散热规模可以大不少这点了

老洋垃圾单核太拉了，我比较倾向于 modt 或者魔改

@lyxxxh2 我倒是很倾向于做东西前先问问豆包，因为豆包乱七八糟的东西集成的比较全。
比如想要做点什么，动手前直接语音问它，想到什么就（语音）补充什么，而且第二次输入语音的时候会自动打断前一次的生成中的文字，体验很好。来回聊几次就能有个比较不错的效果出来了