@wzw #19 简单模式就你直接
1. xxx
2. xxx
3. xxx
然后用 plan 生成计划，然后再执行，但是有一点就是 cursor 生成的 plan 感觉有内置提示词长度限制，就列多了就不详细，就算你要求他非常详细的列出计划也不行

另外的方式就是用各类增强的 workflow
比如 https://github.com/fengshao1227/ccg-workflow
使用 openspec https://github.com/Fission-AI/OpenSpec
这种，执行分析

你的提示词还是类似，还是要求的 1,2,3 这些点，当然为了执行效果好，这些修改点其实都是相近的一批，而不是完全不相关的点

然后就先执行一遍生成修改计划文档，比如 openspec 可以直接生成 70-80 个的 task 文档 + 完整的需求描述 + 代码分析，这些任务是在生成的时候就分析过一遍代码了

接下来就是让 cursor 去执行完成这个 spec 任务，我最长的时候，一个任务跑 3 小时，最多跑出过 40M 的 token ，反正计费也是 2 次

不过 cursor 还是有限制的，大部分情况下跑 10M 就会强制切会话了，所以也不能分太多任务点，一般 20 个左右，一次跑 7-8M 正常，大部分任务都是这样的，生成计划用的 token 会少点，所以其实也可以 claude code 来生成计划，然后 cursor 来执行，我也干过

只要是文件作为媒介的 计划 + 执行，都可以跨工具接力完成，老的 cursor 账号，还是按次计费，你就让他只干长任务，小任务，修 bug 之类的，单独跑 claude code 或者 codex 干就行了，这样总体最划算

加上最近 claude 中转可用性很低，cursor 能不波动的使用 claude opus 4.6 我觉得已经很好了

@JoeDH 我一般都是 cli 跟 IDE 一起开，纯 cli 走 pr review 的话，就感觉类似 github copilot 模式，直接云上跑得了，就是项目得挂在 github 上，公司项目不太行

@LightHiding777 #6 把你的项目用 git worktree 方式切一个分支给 cursor 或者 claude code ，然后在单独的分支上跑，跑完了你可以 idea 切分支过去验证，也可以那边验证通过了 pr 到你的主分支，或者你 idea 里面把 AI 跑的功能提交直接 cherry pick 过来

你不了解 git worktree 的话，直接项目下开个 claude code 教你操作，还有就是 cursor 本身也是直接有 worktree 模式的，在新建对话的底下可以选择

https://i.imgur.com/VRjsmkL.png

现阶段还是旧的按次订阅的，可以大力用，挺划算的

过年的时候 subagent 还不记次数的，某次发现计次数之后，就用提示词强制要求不能启动 subagent 执行了

然后你可以一个提示写好几步需求，让他干一两小时，分析 + 执行 + 复核，搞几个工作流

我这用一半，都 10 亿 token 了，你这 134M 就用完了，也太少了，建议可以优化下工作流，多塞需求进去，然后让他一步步规划 + 执行

https://i.imgur.com/KrH375B.png

赞同楼上的一些说法，我 475+75 散光，配过好多副眼镜，之前有一副因为前一副眼镜突然坏了，急着配的，就随便找了个连锁品牌跟着店员挑了下，就有比较明显的楼主说的这种边缘形变的情况，看地上方格地砖线，非常明显。

当时店员说正常的，戴一段时间适应下就行了，后来也确实神奇，戴了一周多之后，确实适应了，就不那么明显了。

后来多了解之后，有说法是人脑的自适应能力非常强，其实当时配的眼镜就是没那么适配，具体原因可能就像楼上有些说的球面非球面啥的，或者其他的一些细节参数有问题，所以一开始戴上发现有问题，其实就是有问题，后面戴久了，看不出来，就是人脑自动校准了，不过这个适应能力可能因人而异。

我现在戴的后面专门医院验光，然后线上配的蔡司的镜片，就没出现过这个情况了。建议楼主重新配一副。

@tanranran #12 +1 ，前两个月刚新调研开发过微信小程序，uniapp 只开发小程序，就可以不用 hbuildx ，那个实在用不来。

用 https://unibest.tech/ 建的项目，UI 库选的 wot-ui, 整合了下 https://demo.wot-design-uni.cn/ 的部分功能，开发体验跟普通 vue web 开发差不多。

当然因为有些小程序跟 uniapp 的限制，还是有些限制的，特别是二次封装组件，因为不支持 listeners 透传，以及插槽透传也有坑，封装起来非常难受，直接单纯写业务页面+业务组件，用起来倒是还挺好

虽然是只开发微信小程序，但相比用原生选 uniapp 开发，除了原生语法外，还有个有小优点（算是遇到的一个坑，因为是 uniapp 开发的解决起来比较方便）

就是我们开发的页面需要上传用户附件，是 PDF 的那种附件，微信小程序选择文件的 API 有限制，你选图片之类的，可以直接单独拉起相册，但是你上传文件，就只给了一个从聊天文件中选择的 API

导致小程序原生页面只能做成，用户先要把文件发到文件传输助手，然后再选择的效果，后面查了半天说小程序原生页面没辙，只能跳转一个 web-view 页面，使用 web 方式上传文件，这时候可以直接选择手机文件，但是这时候要单独新写一个项目去写一个文件上传页面，上传完之后再把文件地址返回给小程序，就挺麻烦的。

这时候灵机一动，因为 uniapp 可以直接打包成 web 页面发布，所以就直接在小程序项目里面，写了一个文件上传页面，但其实是 only for web 的，然后把项目重新打包发布成 web ，小程序里面再 webview 嵌套用于上传，这样直接一个项目就全搞定了，上传代码逻辑还都是同一份，因为后面跟产品讨论，做成选择了用户既可以从聊天文件中选择（方便电脑发给手机的文件），也可以用 web 方式直接选择手机文件。

参加一下

买个自动合盖的那个立式的牙膏，我们家就用那个，按一下就出来一截，手放开，就自己截断+合盖了，而且没有从下面挤还是中间挤的烦恼，他底下是个硬的立管，平时放，就直接立在台面上

分子+1

分母 + 1

@eurkidu 还有一个常见方案，即如果你这个 A 只是 B 表格数据显示的时候，比如某列是字典表，其他配置表，B 返回数据里面存的是 id ，显示的时候要显示成 A 返回里面对应的 name 。

可以直接写一个计算属性，按照 A 返回的数据，生成新的显示数据
```
get viewTableData() {
// 如果能保证 roleData 一定有值的话，加这个可以让 loading 中的表格显示效果更好
if (this.roleData.length === 0) return []
const data = JSON.parse(JSON.stringify(this.tableData))
data.forEach(row => {
row.roleName = this.roleData.find(v => v.id === row.roleId)?.name ?? ''
})
return data
}
```

然后可以对表格加 loading ，A 数据未返回前，表格处于 loading 中，这样就可以不用关心 A ，B 数据的加载顺序，当然这个逻辑比较偏向固定这个逻辑的页面的写法，不适合通用组件封装的逻辑。

按现有逻辑
方案一，现有逻辑，类似 3 楼思路，合并 A ，B 调用为一个新函数 C ，里面对 A 做单例执行，如果 A 数据有值不重复请求 A 数据。

方案二，把 onMounted 里触发的 A ，前置到 beforeRouteEnter ，保证 A 数据加载了之后，再 next 渲染页面，即把 页面 非表格数据的 loading ，前置到 路由的 loading 中，这也是一种常见的写法。

方案三，一般个人写这种页面，不会去 watch 分页参数，或者即便 watch 也会去掉 immediate 触发，因为大概率 页面首次初始化逻辑是不同于切换分页组件的时候触发逻辑的（当然，对于简单的 CRUD 页面来说可能是一样的）。如果不 watch 分页参数，那逻辑就变成自然的，首次渲染 A + B ，切换分页组件的时候，触发 B 的逻辑。

不 watch 分页的一些原因，主要因为 watch immediate 会在组件 created 的时候直接触发，加上如果修改 watch 参数的逻辑因为组件封装的复杂度，导致用户一次操作，同时修改了 watch 对象的 2 个值，并且 2 次修改有类似 nextTick 的分隔，会导致触发 2 次，如果是手动控制的 change ，就可以规避（依稀记得当年 element-ui 1.0 的时代，el-select 的 change 事件是直接类似 watch 的逻辑，每次修改 v-model 的值，都会触发 change ，写省市区级联选择框的时候，一言难尽，后面 v2 版本就直接改逻辑了，只有用户的操作才会触发 change ）

所以 OP 逻辑里面的 分页调用 B ，从封装组件逻辑角度出发，我是不建议直接 watch 触发逻辑的，应该是用户主动切换页码的时候，才触发 change ，可举个简单的例子，比如需要列表跳转 url 进入详情，详情返回列表还是在原来的页码，一般可通过 url 参数保留之前的页码，这时候 页面初始化会带有比如 ?page=2 这样的参数，如果内部分页组件直接 watch 不做特殊处理，那默认请求第 1 页，拿到 url 参数，再修改当前页为第 2 页，则会额外触发一次分页请求，但是如果不是 watch 实现的，分页触发只会在用户手动切换分页的时候触发，初始化的时候因为第一页逻辑自己控制，可以灵活的处理各类情况。

@foolishcrab #8 同，都用外接键盘的情况下，mac 可以把 opt 跟 cmd 对换，这样复制粘贴这些操作，就跟 win 一致了，不过如果用 mac 内置键盘的话，还是得大拇指，不过我用的多，好像也还习惯了，就刚切过去的时候会容易按错，过一会就好了

分母+1, 试试

@JayZXu #22 恩是的，我也怕 CPU 不升到时候跑不动星空，毕竟最低配置要求写着 6800k ，我都没达到

不过上面 V 友的建议我综合想了下，按自己着预算，真配台新的，估计也就 4070 差不多，70ti 估计要加钱了

那或许可以先买个 4070 的显卡，如果可以别的都不换，插上能好自己用，那可以分段式购物，先用着看看，瓶颈了，就再换剩下的板 U

笔记本的话，我印象中，同级别的显卡，也达不到桌面端的水平吧，主要我也没便携的需求

@heymi #17
我看了下购买记录，老电脑的电源是 EVGA 650 G2 650w 的全模组 电源，显卡供电写着 (6Pin, 6+2Pin) x2, 这个的意思没理解错的话是 一条 6Pin 的，一条 6+2Pin 的电源线的吧

4070 的供电应该是 8Pin 吧 (我看了一张七彩虹的, 写着 8Pin)，或许可以继续用老电源?

@heymi #17

看了下价格，大概 4060ti 在 3000-3500 左右，4070 在 4500-5000 左右

2 者差价 1000-1500 左右，但是看了下极客湾的视频，感觉 60ti 跟 70 比好像挺糟糕的，单买 40 系卡的话，现在看好 4070 ，感觉性价比更高点

感觉 70 的价格，双十一蹲一下，4000 左右能入最好

现在就担心老 U 会不会拖后腿，跟 用 i5-13490f 的相比，4k 下会有多大差别（这个也不知道能上哪查了做参考）

想着如果入 40 系的显卡，那能撑个 2 年，等 50 系出了，如果价格合适，就再把 40 系卡卖了，然后整体换新

@heymi #5
@ToDyZHu #8

先加钱买张 40 系显卡试试，确实是个好想法，可以分批花钱，毕竟看下来大家都还是觉得新买电脑比较好，毕竟不行也可以再凑起来买整套


老硬件除了电源可能不配套以外，可以加直接换么，其它内存啥的没影响么，还有要注意的么

@rationa1cuzz #7
@ToDyZHu #8

之前老婆也说，直接老的卖了，再买新的，但是看了下感觉二手卖不了几个钱，GTX1080 显卡，查了下黄鱼就差不多 800 左右，整机感觉最多 2k 到头了吧，感觉卖了好亏

因为就算打算买了新机，其实老电脑也不是不要用了，就变成备用机这样，其实玩玩老 3A ，或者类似双人成行这样的，都没啥问题，可以给老婆偶尔家里办公用或者玩点要求低的游戏，如果卖了就 2k ，就感觉好亏