@jimx 我是在 Claude code 中让 fable 5 制定计划并保存在一个 markdown 文档中并 commit （或者让 codex 5.6sol 制定计划文档）。然后让 codex 的 5.5/5.4 或者 cursor 中的 grok 4.5 具体实施。文档是任务传递的载体，实施的时候会在提示词中列出文档的路径，负责实施的 agent 会先看列出的计划文档。

任务复杂度，我其实不太能够分辨。我是让 fable 或者 5.6 sol 在审计项目缺陷时列出 P0-Pn ，然后用好模型开发。简单的事项是指项目内的其他文档更新，落地页更新，这些用次一点的模型。

大概率不可以。

个人开发的 ios/macOS app 的商店文案都能不能提及 OpenAI 或者 ChatGPT 。审核人员会提到工信部的规定:

As you may know, the Chinese government has been tightening regulations associated with deep synthesis technologies (DST) and generative AI services, including ChatGPT. DST must fulfill permitting requirements to operate in China, including securing a license from the Ministry of Industry and Information Technology (MIIT) if the services are provided while connected to the Internet.

发布就用了，感觉挺好用的。发现了一个问题，不知道是不是 bug:有时当用户在云笺打开的状态时关闭屏幕的话，过段时间解除锁屏后会显示报错，但立马就能恢复。不晓得软件原因，还是手机原因”moto g100".网络环境不存在问题。

开发后单靠 App Store 推流是很难的。大陆用户，发小红书和其他平台。海外产品就不知道了，据说有人发 reddit ，但我亲测很容易封号。也有人发 tiktok 等平台或者使用 meta 广告的。

降级到 plus 。有了做产品的想法，token 明显不够用了再升为 pro 套餐。

我感觉 plus 套餐就够用了(可能我的项目比较小的原因，最大的也就 6 、7 万行代码）；不够的话再加 cursor 和 Claude code 20$方案就差不多了。

我目前维护者三个项目，并新开发着三个项目。架构设计和疑难复杂用 fable 5 ；常规都是用 codex sol/gpt 5.5 。前两者不够时用 cursor 。落地页和一些问题调研用 cursor 中的 grok 4.5.

牛的👍

opus 4.6 已经是 opus 系列最好的模型了，还是很值的。

新模式 API 用量计费，根本用不到两天。

不过 grok 4.5 挺好用的。我基本上复杂任务 Claude code fable 定计划，codex 实施。其他事项全都用 grok 4.5 ，非常好用。但是总量也有限度。

一天重置两次。昨天早上起来看到重置了一次；刚刚还没用完，又重置了。Tibo 大善人👍

博主这个产品非常简洁，而是本地优先。是我喜欢的风格。准备两周连续使用，不给楼主拖后腿。

华五本科比武汉那个博士含金量高多了。现在大扩招又是申请制，毕业了就能怎么样。现在高校任教非升即走比比皆是，她书还没读就说在向下兼容，实在不可取。没啥意思，你这个收入很高了，在上海继续工作就好了。以后可以考虑在长三角安家吧，武汉就别回了。

看到本帖之后我去试了一下 结果现在把 API 额度用了一半

差不多可以买个一手 moto g100s 8+128 了

不知道各位都是什么巨型项目，20X 居然可以花完。我的 plus 就做两三个小项目，仅仅嚯嚯的勉强够用（还有用其他产品）。

@JaesonWong 不好意思，我是新手。我的理解是打包是要用 Android studio 进行。这个 Android studio 登陆开发者账号可以打包并发到 play console 进行后续的测试之类的。

看样子你开发的所有文件都要给老外。我不清楚怎么搞。我个人理解，你可以需要将项目文件夹整个用传统方式压缩然后传给对方，对方通过 android studio 签名打包并传到 play console ；如果是你将项目内容传到 github 上的话，那么必然有一些忽略上传的内容对方通过 GitHub 看不到。

等高手来回复你。

@kingfire 没开过 ultra 。我都是用默认强度审计现有的项目和解决关键问题，感觉比 codex 还用。

首月 50%优惠： https://cursor.com/referral?code=9ZMGINYC89N1 目前还有 8 个可邀请； 7 号开始数量刷新为 10 个。

我让 GPT 生成了 Claude code 用的 instruction ，还没太能够评判好坏。

You are working in an existing production codebase. Preserve the current architecture,
conventions, and behavior unless the requested task explicitly requires a change.

## Operating principles
- First inspect the relevant code, configuration, README, and existing patterns before editing.
- Treat the repository as the source of truth. Do not assume frameworks, commands, APIs, or conventions.
- Make the smallest correct change that solves the requested problem.
- Do not refactor unrelated code, rename public APIs, reformat large files, or alter project-wide configuration unless explicitly requested.
- When requirements are ambiguous, identify the ambiguity and ask a concise question before making consequential changes.
- Prefer existing utilities, components, patterns, and dependencies over introducing new ones.

## Before coding
- Briefly state the files you expect to inspect or modify and the implementation approach.
- Check for existing tests, linting, formatting, type-checking, and build commands.
- For non-trivial changes, provide a short plan before implementation.

## Implementation standards
- Write readable, maintainable, idiomatic code consistent with the existing codebase.
- Keep functions and components focused; avoid unnecessary abstractions.
- Preserve backward compatibility unless explicitly instructed otherwise.
- Add or update tests when behavior changes or a bug is fixed.
- Handle errors, edge cases, null/empty states, and failure paths appropriately.
- Do not add dependencies unless necessary. Explain why before adding any dependency.
- Do not expose secrets, tokens, credentials, private data, or internal paths in code, logs, or documentation.

## Validation
After making changes:
1. Run the most relevant available checks (tests, type check, lint, build, or targeted command).
2. Report exactly what was changed.
3. Report validation commands run and their results.
4. Clearly state anything not validated and why.
5. Mention any assumptions, risks, or follow-up work.

## Git safety
- Do not create commits, push branches, open pull requests, delete files, or run destructive commands unless explicitly asked.
- Do not modify lockfiles, generated files, environment files, CI configuration, or deployment configuration unless required by the task.

## Communication
- Use concise Chinese for explanations and summaries.
- Use English for code, identifiers, comments, commit messages, and technical terms when consistent with the repository.
- When showing code changes, explain the reasoning rather than only describing the diff.

一年赚不到年费，就别续了吧。注册个号没什么难的。后面想开发，可以再恢复吧。