最新

我想找到一种好的方法，使用像Claude或Codex这样的编码助手在我的（安卓）手机上进行编程。但我找不到任何有效的工具。 我尝试过的： 在手机上使用SSH终端应用。这是可行的，但TUI界面远不算“舒适”，在手机上使用体验很差。 Happy Coder（happy.engineering）号称是解决方案，但我发现它的可靠性很差，无法处理Claude的新问题格式，并且（根据问题和讨论来看）似乎有些被遗弃。 理想情况下，我希望有一个自托管的、优化了移动设备的网页界面，可以让我启动不同的编码会话（如果每个会话都在自己的Docker容器中运行，那就更好了）。重要的是，我不仅仅是被放到一个控制台中，而是界面实际上是为手机使用进行了优化。 你们在外出时使用什么工具来控制编码助手？我是否错过了什么明显的选择？

经过三年多的深度代理编码，我注意到一个模式：Claude、Cursor 和 Copilot 生成的代码虽然能运行，但并不合适。 它通过了测试，能够运行，但却与语言的本质相悖。它在平台提供状态时自行发明状态，使用巧妙的单行代码隐藏因果关系。在同一个文件中为同一个问题创造了三种不同的解决方案。架构在技术上是有效的，但在认知上却很昂贵。 请求“干净代码”并没有帮助。这些代理需要我会给有才华的初级开发者的东西：一本关于品味的手册。 因此，我编写了教义文件——用 Markdown 编写的约束，教导代理区分可编译的代码和可维护的代码。内容包括： - “文件中有超过 20 个可变状态变量？你有多个模块假装成一个。” - “三种解决同一问题的方法共存？选择一种，删除其他的。” - “如果你不能用一句话解释条件，就将其提取为一个命名的布尔值。” AI Lint 是这一理念的产品化。它不是命令行工具或软件即服务，而是优化后的文本文件，你可以将其放入 .cursorrules、AGENTS.md 或你的系统提示中。代理会阅读这些文件并实际遵循它们。 这里有教义（什么是合适的）和拒绝（什么是要拒绝的）。当规则冲突时，有一个覆盖协议。它是为上下文注入设计的，而不是为了人类阅读。 商业模式：为不同的技术栈（应用、系统等）提供付费包。但我已在 GitHub 上发布了一个免费的预览，包含核心理念和 JavaScript/Node.js 的教义，以便你测试其影响。 - 网站: [https://ai-lint.dosaygo.com](https://ai-lint.dosaygo.com) - 免费预览: [https://github.com/DO-SAY-GO/AI-Lint](https://github.com/DO-SAY-GO/AI-Lint) 我对 AI 不断注入到你的代码库中的反模式感到好奇。目前我正在扩展 Go 和 Rust 的拒绝规则，并计划接下来推出 iOS/Swift 和基础设施（Docker、k8s）包。

# 我的英语不好，这段内容是由AI翻译的。 <p>一种分布式架构，其中业务逻辑和渲染完全分离。</p> <p>1. 核心理念：停止发送“绘制命令”，开始发送“意图”。</p> <p>目前，GUI开发（无论是本地应用还是网页应用）仍然紧密耦合。我一直认为业务层和GUI层应该完全分离，这实际上与云计算的方向非常契合。</p> <p>我设想的是一种以意图驱动的架构。后端不再发送布局、样式、JS代码等，而是通过某种协议仅发送意图、语义和描述性数据。</p> <p>大致分为三个部分：</p> <p>1. 业务层 业务代码保持不变。开发者无需考虑UI细节。一个小的“语义接口”将业务操作转换为抽象的意图。</p> <p>2. 意图协议 该协议仅描述意图、语义和数据。 示例：发送“选择日期”，而不是“打开样式为X的日历小部件”。 它可以在内存、进程间通信或网络上运行。</p> <p>3. 渲染引擎 一个自包含的引擎，解释意图并在本地渲染UI。 所有纯UI逻辑（组件、约束、动画等）都保留在引擎内部，而不调用业务层。</p> <p>2. 可能的应用场景</p> <p>- 本地GUI应用 将业务逻辑、协议和引擎打包成一个程序。无需网络支持。只需像库一样链接引擎，并根据需要加载组件/插件。</p> <p>- 现代网页应用 后端运行业务逻辑，并通过HTTP发送意图。 浏览器基本上变成了一个具有高复用性的自定义渲染引擎。</p> <p>- 云端 + 轻客户端 类似于网页模型：业务在云端运行，渲染引擎作为轻量级客户端在本地运行。 一个引擎可以服务多个云应用，并可以热更新组件以获得新的渲染能力。</p> <p>3. 这可能有趣的原因</p> <p>- 无交互延迟 UI逻辑在本地运行，因此即使在分布式设置中也能保持流畅。</p> <p>- 极致复用 业务和渲染完全解耦。任一方都可以轻松替换。</p> <p>- 清晰的关注点分离 前端决定布局和样式；后端专注于业务逻辑。</p> <p>- 超越普通应用的潜力 如果协议足够强大，这甚至可以驱动复杂的3D应用或游戏。</p> <p>4. 难点</p> <p>- 自动布局 很难做到好，尤其是当需要看起来美观时。早期版本可能需要简单或固定的布局。</p> <p>- 组件/插件系统 在引擎内部处理约束、交互、动画等并不容易设计。</p> <p>- 协议设计 过于详细 → 后端最终会微观管理前端。 过于模糊 → 前端缺乏必要的信息。 而在不发送代码的情况下描述UI逻辑是一个很大的挑战。</p>