Cloudflare Tunnel（零暴露，快速上线）详解​

Cloudflare Tunnel（原 Argo Tunnel）是 Cloudflare Zero Trust 架构的核心组件，它通过出站连接模型实现服务的公网暴露，彻底消除了传统方案中端口开放、公网 IP 依赖等安全风险，同时具备分钟级部署的极致效率。

核心优势：零暴露架构​

1. 无公网 IP，无端口开放

• 原理：在服务器上运行 cloudflared 守护进程，主动建立到 Cloudflare 边缘网络的出站加密隧道。外部请求无法直接访问源站，只能经 Cloudflare 边缘节点通过隧道转发。
• 安全价值：攻击者无法扫描到源站 IP 和开放端口，DDoS 攻击被 Cloudflare 全球网络吸收，源站完全隐身。

2. 默认 HTTPS，证书自动管理

• Cloudflare 自动为域名签发并续期 SSL 证书，外部访问全程加密，无需手动配置 Let's Encrypt 等证书服务。

3. 身份验证集成

• 可配合 Cloudflare Access 实现 OAuth、MFA 等多因素认证，构建零信任访问控制体系。

快速上线：5 分钟部署实战​

根据真实配置实践，完整部署流程仅需 5 个核心步骤：

步骤 1：安装 cloudflared​

# 下载最新版本（支持 Linux/Windows/macOS）
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared && sudo mv cloudflared /usr/local/bin/
cloudflared --version

步骤 2：认证并创建隧道​

# 浏览器授权选择域名
cloudflared tunnel login

# 创建命名隧道（自动生成凭证文件）
cloudflared tunnel create my-tunnel
# 输出隧道 ID：167e64e3-17b5-4bf8-bd7b-f7691f658416

步骤 3：配置路由规则​

创建配置文件 /etc/cloudflared/config.yml：

tunnel: my-tunnel
credentials-file: /etc/cloudflared/167e64e3-17b5-4bf8-bd7b-f7691f658416.json
ingress:
  # HTTP 服务示例
  - hostname: app.yourdomain.com
    service: http://localhost:8080
  # SSH 服务示例
  - hostname: ssh.yourdomain.com
    service: ssh://localhost:22
  # 兜底规则（必需）
  - service: http_status:404

步骤 4：配置 DNS 记录​

# 自动创建 CNAME 记录指向隧道
cloudflared tunnel route dns my-tunnel "app.yourdomain.com"
cloudflared tunnel route dns my-tunnel "ssh.yourdomain.com"

步骤 5：启动服务​

# 创建 systemd 服务（推荐生产环境）
sudo tee /etc/systemd/system/cloudflared.service > /dev/null <<'EOF'
[Unit]
Description=cloudflared tunnel
After=network-online.target
[Service]
ExecStart=/usr/local/bin/cloudflared --config /etc/cloudflared/config.yml tunnel run
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared

完成！ 等待 1-2 分钟，访问 https://app.yourdomain.com 即可看到内网服务。

技术架构对比​

适用场景​

• 家庭服务器/NAS 远程访问：无需公网 IP 或动态域名
• 开发测试环境：快速将本地服务暴露给协作方
• 企业内网应用发布：配合 Zero Trust 实现员工安全访问
• 混合云架构：打通多云与本地数据中心

性能与成本​

• 免费额度：个人用户免费套餐足够使用，包含无限隧道数量和充足流量
• 网络加速：自动利用 Cloudflare Argo Smart Routing，通过私有骨干网传输，延迟通常低于传统 CDN 回源
• 协议优化：支持 HTTP/2、QUIC 等现代协议，连接复用减少握手开销

最佳实践​

1. Docker 部署（推荐）：

   services:
     cloudflared:
       image: cloudflare/cloudflared
       restart: always
       command: tunnel --no-autoupdate run --token YOUR_TUNNEL_TOKEN
   

2. 多服务隔离：为不同服务创建独立子域名，便于权限管理

3. 监控告警：配置 Cloudflare 仪表板监控隧道状态

4. 安全加固：对敏感服务启用 Cloudflare Access 身份验证

Cloudflare Tunnel 通过颠覆性的出站连接模型，实现了真正的零暴露安全架构，其快速上线能力让个人开发者和企业都能在分钟级完成生产环境的部署，是现代内网穿透和零信任架构的首选方案。

微信公众号​

自建FRP能让你安全地将内网服务暴露到公网，非常适合远程访问、开发调试等场景。下面是一份清晰的搭建指南。

🎯 理解核心概念​

FRP的工作方式依赖于两个核心组件：

• 服务端 (frps)：需要安装在一台拥有公网IP地址的服务器上（例如云服务商的云服务器）。它作为流量中转的“门户”或“交通枢纽”。
• 客户端 (frpc)：安装在你内网中需要被访问的设备上（如家里的NAS、办公电脑）。它负责与公网上的服务端建立连接，并将内网服务的流量转发出去。

简单来说，当外网用户想要访问你内网的服务时，请求先发送到公网服务器上的frps，然后frps通过已建立的连接将请求转发给内网设备上的frpc，最终送达目标服务。

🛠️ 搭建操作指南​

第一步：配置FRP服务端 (frps)​

1. 下载与安装 通过SSH连接到你的公网服务器，使用 wget 或 curl 命令从FRP的GitHub发布页下载最新版本的二进制包，然后解压。请根据你的服务器操作系统选择正确的版本。

   # 进入一个合适的目录，例如 /opt
   cd /opt
   # 下载（版本号请替换为最新版）
   sudo wget https://github.com/fatedier/frp/releases/download/v0.61.1/frp_0.61.1_linux_amd64.tar.gz
   # 解压
   sudo tar -zxvf frp_0.61.1_linux_amd64.tar.gz
   # 进入解压后的目录
   cd frp_0.61.1_linux_amd64
   

2. 编辑配置文件 关键的步骤是配置服务端，主要修改 frps.toml 文件。以下是一个基础配置示例：

   [common]
   # 服务端监听的端口，客户端将通过此端口连接
   bindPort = 7000
   # 如果您希望通过网页查看frp状态，可以启用仪表盘
   dashboard_addr = "0.0.0.0"
   dashboard_port = 7500
   dashboard_user = "admin"  # 请设置一个安全的用户名
   dashboard_pwd = "your_secure_password"  # 请设置一个强密码
   # 强烈建议设置token认证，提升安全性
   auth.method = "token"
   auth.token = "a_very_long_and_secure_secret_token"
   

   如果需要穿透HTTP/HTTPS服务，可能还需要配置 vhostHTTPPort 和 vhostHTTPSPort 等参数。

3. 启动服务与设置开机自启 为了管理方便，建议将frps配置为系统服务（如使用systemd）。

   • 创建一个service文件，例如 /etc/systemd/system/frps.service。
   • 使用 sudo systemctl daemon-reload 重新加载配置。
   • 使用 sudo systemctl start frps 启动服务。
   • 使用 sudo systemctl enable frps 设置开机自启。

4. 配置防火墙 务必在服务器的防火墙（如iptables、firewalld）以及云服务商的安全组规则中，放行frps服务配置中使用的端口（例如上面的7000和7500端口）。

第二步：配置FRP客户端 (frpc)​

1. 下载客户端软件 在内网设备上下载并解压与服务端相同版本的FRP软件包。

2. 编辑配置文件 客户端的配置文件是 frpc.toml。你需要告诉它如何连接到服务端，以及映射哪些服务。

   [common]
   # 填写你公网服务器的IP地址或域名
   serverAddr = "your_server_public_ip"
   serverPort = 7000
   # 此处的token必须与服务端配置的token完全一致
   auth.method = "token"
   auth.token = "a_very_long_and_secure_secret_token"
   
   # 下面开始定义具体的代理规则
   # 示例1：映射内网的SSH服务（22端口）
   [[proxies]]
   name = "ssh-to-my-pc"
   type = "tcp"
   localIP = "127.0.0.1"
   localPort = 22
   # 在公网服务器上使用这个端口来访问内网SSH
   remotePort = 6000 
   
   # 示例2：映射内网的Web服务（例如在3000端口）
   [[proxies]]
   name = "web-app"
   type = "tcp"  # 简单的TCP代理，对于HTTP服务也可使用"http"类型以获得更多功能
   localIP = "127.0.0.1"
   localPort = 3000
   remotePort = 6001
   

3. 启动客户端 在内网设备上，进入FRP目录，执行启动命令：

   ./frpc -c ./frpc.toml
   

   同样，也可以将frpc配置为系统服务或后台进程，以确保稳定运行。

🔒 重要安全提醒​

自建服务意味着你需要自己负责安全，以下几点至关重要：

• 使用强令牌：配置文件中的 auth.token 是首要的安全屏障，务必使用长且复杂的随机字符串，并定期更换。
• 最小化端口开放：在服务器防火墙和云服务商安全组中，只开放frp服务所必需的端口，关闭所有不必要的端口。
• 关注日志：定期检查frps和frpc的日志输出，留意是否有异常连接尝试。
• 考虑TLS加密：对于传输敏感数据的场景，FRP支持TLS加密通信，建议在配置中启用。

💎 进阶配置与故障排查​

成功完成基础搭建后，你可能还需要了解一些进阶配置和问题处理方法。

• 使用域名（虚拟主机）：如果你拥有一个域名，可以配置FRP，让不同的子域名（如 panel.your-domain.com）指向内网中不同的Web服务，这比直接使用IP地址和端口号更优雅、易用。
• 常见问题排查：
  • 连接失败：首先确认服务端防火墙和安全组规则已正确放行所有相关端口（如 bindPort, dashboard_port, 以及客户端配置的 remotePort 等）。这是最常见的问题。
  • 检查配置：确保客户端配置中的 serverAddr（公网服务器IP）和 serverPort 准确无误。
  • 核对认证信息：再三确认客户端和服务端的 auth.token 完全一致。
  • 查看日志：通过服务端和客户端的日志输出（使用 sudo systemctl status frps 或直接运行程序查看输出），可以获取非常详细的错误信息，这是定位问题的关键。

希望这份指南能帮助你顺利搭建自己的FRP服务！如果你在具体操作中遇到更细致的问题，比如如何为特定服务（如Windows远程桌面）配置代理，我很乐意提供进一步的建议。

微信公众号​

Cursor 与 Serena 的组合，被广泛认为是一次质的飞跃，它将一个优秀的AI编辑器（Cursor）与一个强大的“IDE大脑”（Serena）相结合，彻底改变了AI辅助编程的体验。其核心关系可以概括为：Cursor 是灵敏的“外卖骑手”，负责与用户交互和最终交付；而 Serena 是智慧的“中央厨房”，负责深度分析代码库并提供精准的解决方案。

以下表格清晰地展示了两者如何分工协作：

🔧 核心能力与工作原理​

Serena 的强大之处在于它为AI赋予了类似IDE的智能。

• 符号级语义检索：Serena 提供的工具（如 find_symbol, find_referencing_symbols）允许AI查找的是代码中的“实体”（如函数、类、变量），而不仅仅是字符串。这意味着AI能精准定位一个函数的定义及其在所有文件中的引用，避免手动Ctrl+F的遗漏和错误。
• 精准“手术刀式”编辑：与传统AI工具经常替换整个文件不同，Serena 支持 insert_before_symbol、replace_symbol_body 等操作，允许AI进行精准的插入或替换，像做外科手术一样修改代码，极大提升了修改的安全性和可控性。
• 项目级上下文理解：Serena 在项目加载时会进行“Onboarding”，分析代码结构并生成记忆（存储在 .serena/memories/ 目录下）。后续的对话可以复用这些记忆，使得AI能像一位逐渐熟悉你项目的新队友，越来越了解项目的架构和规范。

🚀 实际应用场景​

当你组合使用Cursor和Serena时，可以这样高效地完成复杂任务：

• 安全的重构：你可以指令AI“将项目中的 fetchDataV1 函数重命名为 fetchDataV2，并更新所有引用处”。Serena会利用其重构能力安全地完成重命名，并确保所有依赖关系同步更新。
• 跨文件功能添加：指令“为我的React项目添加一个用户个人资料页面”。AI会通过Serena分析现有路由、组件和API，自动创建新组件、在合适的位置添加路由、并生成相关的样式和逻辑代码。
• 精准的Bug修复：指令“修复登录功能中密码错误时提示信息不显示的问题”。AI会定位到登录相关的代码文件，分析逻辑流，并精准地插入或修改错误处理代码。

⚙️ 配置指南​

配置过程主要分为三步：

1. 安装uv包管理器：Serena推荐使用uv来管理运行环境。可以通过一条命令安装：

   # Windows (PowerShell)
   powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
   # macOS/Linux
   curl -LsSf https://astral.sh/uv/install.sh | sh
   

2. 启动Serena MCP服务器：在终端中运行以下命令，启动Serena服务。

   uvx --from git+https://github.com/oraios/serena serena-mcp-server
   

3. 在Cursor中配置MCP：在Cursor的设置中，找到MCP Servers配置项，添加以下配置并重启Cursor。

   {
     "mcpServers": {
       "serena": {
         "command": "uvx",
         "args": ["--from", "git+https://github.com/oraios/serena", "serena-mcp-server"]
       }
     }
   }
   

💎 组合优势总结​

总而言之，Cursor+Serena的组合带来了以下颠覆性优势：

• 从“辅助”到“协作”：AI不再是简单的补全工具，而是能深度参与项目开发、理解上下文的协作伙伴。
• 质变的效率提升：对于中型及以上规模的项目，尤其是进行重构、二次开发或添加复杂功能时，该组合能带来数倍的效率提升，避免了大量手动查找和复制粘贴的工作。
• 显著的Token节约：通过符号级操作和项目记忆，避免了让AI反复阅读大量文件内容来获取上下文，从而节省了大量Token消耗。

希望这份解读能帮助您全面了解Cursor与Serena这个强大的组合。如果您在配置或使用中遇到任何具体问题，我很乐意提供进一步的帮助。

微信公众号​

微信公众号​

想让 Cursor 这个强大的 AI 编程助手既高效又省钱，核心在于理解其运作机制并掌握一些关键技巧。下面我为你整理了一份从基础到进阶的实用指南。

💸 理解 Cursor 的计费方式​

首先，清楚钱花在哪里是节约的第一步。Cursor 的计费主要基于以下两种模式之一：

• 按交互次数计费：在某些版本中，你与 AI 的一次问答（你提问，AI 一次回答）被视为一次交互。每个计费周期通常有免费的交互额度，用完后需要付费或使用慢速队列 。
• 按 Token 计费：这是更本质的计费单位。Token 是 AI 处理文本的基本单位，可以理解为字符或单词。总消耗 = 输入 Token + 输出 Token + 上下文 Token。你提供给 AI 的提示、AI 生成的代码/文本、以及对话历史中所有需要被 AI“记住”的内容都会消耗 Token 。

基于以上计费原理，可以采取以下节约策略。

🧠 优化你的提问方式​

高效的提问能显著减少来回沟通的次数和无效输出。

• 需求明确具体：避免模糊的指令。与其说“帮我写个函数”，不如详细说明技术栈、具体功能、约束条件等 。
  • 不推荐：帮我写代码
  • 推荐：用React Hooks实现一个计数器组件，要求具备增加、减少、重置功能，使用TypeScript编写，状态通过useState管理 。
• 分阶段处理复杂任务：对于大型功能，不要试图在一个对话中完成。将其拆分为设计、核心功能实现、异常处理、优化等阶段，分步进行。这比一次性请求能节省大量 Token 。
• 先要方案，再要代码：对于复杂逻辑，可以先开启 Plan Mode 或直接提示 AI 先给出实现计划和方案。你确认方案可行后，再让它生成代码，避免在错误方向上浪费额度 。

🔧 善用工具与控制上下文​

上下文管理是控制 Token 消耗的关键，因为对话历史越长，消耗的 Token 越多。

• 精准引用上下文：使用 @ 符号精确地告诉 AI 需要关注哪些文件、文档或过去的对话 (@file, @docs, @past chats)，而不是让 AI 自动加载可能不相关的全部上下文 。
• 管理对话长度：避免所有对话都在一个窗口中进行。为不同的、复杂的任务开启新的独立对话框，以保持每个对话的上下文简洁，减少幻觉和 Token 浪费 。
• 活用 NotePads：对于冗长的需求文档或接口说明，可以先将内容整理到 NotePads 中。在新对话中直接 @NotePads，就能让 AI 基于所有内容生成代码，避免在对话框中粘贴大量文本 。
• 配置 .cursorignore 文件：将项目中不需要被 AI 索引的文件（如 node_modules, 构建产物、日志文件等）忽略掉，可以减少 AI 构建索引时的负担和无关上下文的干扰 。

⚙️ 精细配置与模型选择​

• 选择合适的模型：Cursor 提供多种 AI 模型。对于简单的代码补全、行内修改（Ctrl/Cmd + K），默认的 gpt-4o-mini 等较轻量模型通常足够且便宜。处理复杂架构设计时，再切换至 Claude 3.5/3.7 等更强但更贵的模型 。
• 智能配置 Project Rules：Project Rules 是指导 AI 行为的项目规范，但它本身也会作为上下文消耗 Token 。
  • 模式选择：对于个人或小型项目，建议使用 Selective Apply（选择性应用）模式，仅在需要时通过 @rules 触发相关规则，这比 Always Apply（始终应用）模式更节省 Token 。
  • 规则优化：将规则分级，只将最关键的规定（如安全规则、基础命名规范）设为核心规则。同时，尽量使用简洁的语言编写规则 。

下面的表格对比了不同规则应用模式的优缺点 ：

💎 核心省钱口诀​

总结一下，最核心的节约心法如下：

希望这些技巧能帮助你更高效、更经济地使用 Cursor。如果你对某个特定功能（比如 Rules 的详细配置或 Agent 模式的高级用法）有进一步兴趣，我很乐意提供更具体的介绍。

编写高效的 Project Rules 确实是一门平衡艺术，既要让 AI 精准产出高质量代码，又要避免不必要的资源消耗。下面这个表格总结了高效 Rules 的四大核心原则，你可以先快速了解其精髓。

🛠️ 编写高质量规则的具体方法​

掌握了核心原则后，我们来看看如何将它们付诸实践。

1. 使用命令式、否定式语言 规则的本质是指令，而非建议。使用果断、明确的语气，能显著提高 AI 的服从度 。

   • 不推荐 (模糊、解释型)：“建议优先使用函数式组件。”
   • 推荐 (命令式)：“使用 React 函数式组件和 Hooks。”
   • 推荐 (否定式)：“禁止绕过 Repository 层直接操作数据库。”

2. 采用新的 .cursor/rules/ 目录结构 放弃传统的单一 .cursorrules 文件。现在更推荐的做法是在项目根目录创建 .cursor/rules/ 文件夹，然后将规则分门别类地存放在不同的 .mdc 文件中 。这样做的好处是结构清晰，便于维护，并能更好地与 RuleType 配合实现精准引用。

3. 善用 RuleType 实现精准控制 在每个 .mdc 文件的顶部，你可以通过 YAML front matter 定义 RuleType，这是实现 Token 节省的关键 。

   • Always：始终生效的通用规则，如项目核心行为、通用代码风格。
   • Apply to Specific Files：仅当编辑特定类型文件（如 *.py）时才生效，专用于语言或框架规则。
   • Apply Manual：仅在聊天中通过 @规则文件名 显式引用时才生效，适合不常用的特定规则。

💾 最大化节省 Token 的实战技巧​

1. 利用 Cache Read 机制 在同一对话中，AI 对已读过的内容（包括规则文件）的后续读取成本会大幅降低 。因此，应将相关任务放在同一个对话中完成，而不是每个小任务都开启新对话。

2. 规则内容本身要精炼

   • 避免解释性语言：规则中不要写“为什么”，只写“做什么”和“不做什么” 。
   • 多用示例代码：对于复杂的模式或规范，一个简短的代码示例比大段文字描述更有效且更省 Token 。

3. 将规则文件纳入版本控制 这不仅便于团队协作，还能确保所有成员和 AI 都基于同一套最新的规则进行开发，避免因规则不一致导致的重复修改和 Token 浪费 。

🔍 验证规则是否生效​

编写规则后，需要进行测试。你可以尝试让 AI 做一个明显违反规则的操作（例如：“给这个函数添加功能，先不用写测试”）。如果 AI 拒绝执行并提醒你需要遵守测试规则，说明规则已成功生效 。

希望这份指南能帮助你打造出既高效又经济的 Project Rules。如果你在实践过程中遇到具体问题，比如针对某个特定框架的规则编写，我很乐意提供更进一步的探讨。

微信公众号​

实现通过 Email 与 Claude Code 对话的核心方案是使用开源工具 Claude Code Remote。它通过邮件收发机制实现远程控制，非常适合长任务监控和移动办公场景。

核心实现原理​

该工具采用 邮件中继 方式工作：

1. 任务完成通知：本地 Claude Code 执行完任务后，自动发送结果邮件到你的邮箱
2. 指令回复：你直接回复该邮件，在正文中写入新指令
3. 自动执行：监控服务检测到白名单邮箱的回复后，自动将指令发送给 Claude Code
4. 循环交互：重复上述流程，实现连续的远程对话

完整配置步骤​

前期准备​

• Node.js 18+ 环境
• 一个支持 IMAP/SMTP 的邮箱（如 Gmail、Outlook）
• tmux 终端复用工具

安装配置​

# 克隆项目
git clone https://github.com/JessyTsui/claude-code-remote
cd claude-code-remote

# 安装依赖
npm install

# 配置环境变量
cp .env.example .env

编辑 .env 文件，填入邮箱配置和白名单：

EMAIL_USER=your-email@gmail.com
EMAIL_PASS=your-app-password
ALLOWED_SENDERS=your-phone-email@gmail.com,your-colleague@company.com

启动服务​

需要 两个终端窗口 配合运行：

终端 1：启动邮件监控服务

npm run relay:pty
# 显示 "🚀 Claude Code Remote is running! 📧 Monitoring emails..." 即成功

终端 2：在 tmux 中启动 Claude Code

# 创建新会话
tmux new-session -s my-claude-session

# 在 tmux 中正常启动 Claude
claude

使用流程演示​

1. 发起任务：在 tmux 的 Claude 界面输入指令

   分析当前目录下所有 Python 文件的复杂度
   

2. 接收通知：任务完成后，邮箱收到标题为 "Claude Code Remote Task Complete [#ABC123]" 的邮件

3. 回复指令：直接回复邮件，正文写：

   把结果生成一个 Markdown 报告，保存到 reports/ 目录
   

4. 自动执行：回到 tmux 窗口，会看到 Claude 自动接收新指令并执行

5. 持续交互：可无限循环回复邮件，直到任务完成

关键特性与优势​

注意事项​

1. 邮箱安全：建议使用应用专用密码而非主密码
2. Token 消耗：每次邮件交互都会消耗 Claude API 额度，重度使用月费约 $100-200
3. 超时设置：长时间未操作的会话会自动失效，需重新启动
4. 环境分离：生产环境建议单独配置 .env.production 文件

该方案已验证可行，多个开发者正在使用。如需更轻量级的实现，也可以基于 Python 编写简易邮件监控脚本调用 Claude API，但完整功能推荐使用 Claude Code Remote 项目。

微信公众号​

ubuntu​

网络配置:安装网卡驱动​

sudo apt update
sudo apt install bcmwl-kernel-source

AI不间断运行​

邮件往来审批 AI 执行

微信公众号​

在中国软件开发实践中，需求分类已形成与国际接轨且符合本土管理规范的完整体系。以下是基于国内主流方法论（如软考、ASPICE标准、GB/T标准）及行业实践整理的需求分类框架：

一、按抽象级别和来源划分（三级需求体系）​

这是中国软件工程领域最标准的分层方式，广泛应用于系统集成、政企项目及大型产品开发：

1. 业务需求（Business Requirements）​

• 定义：组织或业务部门的高层次目标，关注"为什么要做"
• 来源：客户高层、业务战略、市场分析
• 示例："提升订单处理效率30%"、"实现跨部门数据打通"
• 文档形式：项目愿景与范围文档、商业论证

2. 用户需求（User Requirements）​

• 定义：最终用户对系统的期望，描述"用户想要什么"
• 获取方式：访谈、问卷、用户故事、场景分析
• 示例："用户能通过手机号快速注册"、"支持批量导入Excel数据"
• 文档形式：用户故事（敏捷）、用例规约（传统）

3. 系统需求（System Requirements）​

• 定义：系统必须实现的具体技术特性和约束，说明"系统必须做什么"
• 子类型：
  • 功能需求：具体功能点（如"登录验证需支持短信验证码"）
  • 非功能需求：性能、安全性、可靠性等质量属性（如"响应时间≤3秒"）
• 文档形式：软件需求规格说明书（SRS）

追溯关系：业务需求 → 用户需求 → 系统需求（双向可追溯性）

二、按性质划分（功能 vs 非功能）​

这是开发团队执行层面的核心分类，直接影响技术方案：

功能需求（Functional Requirements）​

• 定义：系统必须完成的业务功能或服务
• 占比：通常占需求总数的60-70%
• 示例：
  • 用户登录、权限管理
  • 订单创建、支付处理
  • 数据导入导出
• 验证方法：功能测试、接口测试

非功能需求（Non-functional Requirements，NFR）​

• 定义：系统应满足的质量属性或约束条件
• 关键类别：

  类别	说明	示例
  性能需求	响应时间、吞吐量	"支持1000并发用户"
  安全性需求	数据保护、访问控制	"符合等保2.0三级要求"
  可靠性需求	可用性、容错性	"系统可用性≥99.9%"
  兼容性需求	软硬件环境适配	"支持Android 8.0+"
  可维护性	代码规范、扩展性	"采用微服务架构"
  合规性需求	法律、行业标准	"符合GDPR数据保护条例"

国内实践要点：非功能需求在合同验收中占比越来越高，尤其是政府项目对安全和性能有强制性要求。

三、按优先级划分（MoSCoW与Kano模型）​

中国项目管理中常用的优先级划分方法：

1. MoSCoW方法​

• Must Have（必须有）：核心功能，不满足则项目失败
• Should Have（应有）：重要功能，但可延期实现
• Could Have（可以有）：增值功能，资源允许时实现
• Won't Have（暂不需要）：明确排除在本次范围外

2. Kano模型​

将需求分为三类：

• 基本需求：必须满足，否则用户极度不满（如系统稳定性）
• 期望需求：满足程度与用户满意度成正比（如界面美观度）
• 兴奋需求：超出预期，带来惊喜（如AI智能推荐）

四、其他重要分类维度​

1. 产品与过程需求​

• 产品需求：对软件本身的要求（如"验证用户输入合法性"）
• 过程需求：对开发过程的约束（如"必须使用Java开发"、"需通过CMMI三级评审"）

2. 接口需求​

• 用户接口：UI/UX设计规范
• 硬件接口：设备、传感器连接要求
• 软件接口：第三方API、中间件集成
• 通信接口：协议、数据格式（如RESTful API）

3. 派生需求 vs 基本需求​

• 基本需求：用户直接提出的原始需求
• 派生需求：从技术实现或系统约束推导出的间接需求（如"因安全要求需增加日志审计功能"）

五、中国本地化实践特点​

1. 政策与合规驱动分类​

• 监管需求：如《数据安全法》《个人信息保护法》要求的数据存储、跨境传输限制
• 信创适配需求：国产CPU（鲲鹏、飞腾）、操作系统（统信UOS、麒麟）、数据库适配
• 等保/分保需求：明确的安全等级保护要求

2. 招投标导向分类​

在政企项目中，需求常被分为：

• 实质性需求：必须响应，否则废标（功能、性能指标）
• 非实质性需求：评分项（界面美观、培训服务等）

3. 敏捷开发中的需求分层​

国内互联网大厂普遍采用：

• Epic（史诗）：跨多个迭代的业务目标
• Feature（特性）：可交付的用户价值模块
• User Story（用户故事）：可在一个迭代内完成的细粒度需求
• Task（任务）：开发任务

六、需求分类的最佳实践​

1. 尽早建立可追溯性：使用需求管理工具（如Jira、PingCode、Ones）建立业务需求到代码的双向追溯
2. 量化非功能需求：避免"快速响应"等模糊描述，必须量化（如"95%请求响应小于1秒"）
3. 分类评审机制：每类需求由不同角色评审（业务需求-客户签字，系统需求-架构师评审）
4. 动态调整：采用敏捷模式，每迭代重新评估优先级，适应市场变化

通过清晰的需求分类，中国软件团队能有效应对需求蔓延、评审效率低、验收标准模糊等常见问题，也是通过软考高级系统分析师、CMMI/ASPICE认证的关键能力要求。

微信公众号​

状态管理

• 页面回退的时候恢复状态

时间范围​

过去一周（基于 Git 提交记录）

主要工作内容​

1. 品牌管理模块优化 ⭐​

1.1 筛选功能实现​

• 文件: src/screens/crm/brand/filter.tsx
• 功能: 实现了品牌列表的右侧抽屉筛选功能
  • 标签筛选（待完善）
  • 品牌编号筛选
  • 创建人筛选
  • 最后修改时间筛选（支持多个时间段选项）
  • 自定义时间段筛选
  • 筛选条件清除功能
• 技术亮点:
  • 使用 Drawer Navigator 实现右侧抽屉
  • 集成 Jotai 进行状态管理
  • 使用 Tailwind CSS 进行样式设计

1.2 品牌列表组件化重构​

• PR: #14, #21
• 改进内容:
  • 将大型组件拆分为多个子组件：
    • BrandCard.tsx - 品牌卡片组件
    • BrandFilterBar.tsx - 筛选栏组件
    • BrandFilterModal.tsx - 筛选模态框
    • BrandSearchAndActionBar.tsx - 搜索和操作栏
    • BrandSortModal.tsx - 排序模态框
    • BrandWatermark.tsx - 水印组件
  • 代码行数从 1315 行优化到更合理的结构
  • 提升了代码可维护性和可复用性

1.3 品牌详情页优化​

• PR: #20
• 改进内容:
  • 修复类型定义问题
  • 优化 UI 展示逻辑
  • 改进数据加载和错误处理

2. 状态管理优化 🎯​

2.1 Jotai Store 工具实现​

• 文件: src/utils/jotaiStore.ts (新增)
• 功能: 实现了页面级别的 Jotai Store 管理工具
  • usePageStore - Hook 方式创建页面级 store
  • usePageBlur - 监听页面返回事件
  • createPageStore - 非 Hook 方式创建 store
• 优势:
  • 自动在页面返回时重置状态
  • 避免状态污染
  • 提供更好的状态隔离

2.2 全局状态管理改进​

• PR: #15
• 改进内容:
  • 添加全局 loading 引用
  • 改进导航类型定义
  • 优化状态管理结构

3. 存储系统迁移 💾​

3.1 MMKV 迁移​

• PR: #17
• 改进内容:
  • 移除 react-native-storage 和 async-storage
  • 全面迁移到 react-native-mmkv (v4)
  • 实现多实例架构优化
  • 提升存储性能（同步读写，高性能）

3.2 存储工具优化​

• 文件: src/utils/mmkv.ts
• 改进内容:
  • 优化存储辅助函数
  • 改进错误处理
  • 添加类型安全

4. 导航系统优化 🧭​

4.1 导航性能优化​

• PR: #16
• 改进内容:
  • 实现懒加载（Lazy Loading）
  • 添加性能监控
  • 实现导航持久化
  • 优化导航结构
• 新增文件:
  • src/navigation/performance-monitor.ts - 性能监控
  • src/navigation/persistence.ts - 持久化
  • src/navigation/helpers.ts - 辅助函数
  • src/navigation/exports.ts - 导出管理

4.2 导航安全性改进​

• PR: #22
• 改进内容:
  • 改进错误处理机制
  • 添加导航安全检查
  • 优化加载状态管理

5. API 客户端优化 🔌​

5.1 API 客户端重构​

• PR: #19
• 改进内容:
  • 从 JavaScript 迁移到 TypeScript
  • 改进错误处理
  • 优化请求拦截器
  • 添加类型安全

5.2 请求头管理集中化​

• PR: #18
• 改进内容:
  • 实现请求头集中管理
  • 自动设置 Organization-Id 和 corporation-id
  • 支持语言和时区请求头
  • 改进请求头缓存机制
• 新增文件:
  • src/utils/requestHeaders.ts - 请求头管理
  • src/utils/language.ts - 语言工具

6. 代码结构优化 🏗️​

6.1 组件化和模块化​

• PR: #21, #13
• 改进内容:
  • 移除未使用的 API 定义和表单组件
  • 改进组件结构
  • 优化导入导出
  • 清理冗余代码

6.2 错误处理改进​

• PR: #22, #12
• 改进内容:
  • 统一错误处理机制
  • 改进错误边界
  • 优化错误提示

7. UI/UX 优化 🎨​

7.1 Tailwind CSS 迁移​

• PR: #8
• 改进内容:
  • 将 UI 组件迁移到 Tailwind CSS
  • 使用 Tailwind 3.4.17 版本
  • 优化样式代码

7.2 @rneui/themed 集成​

• PR: #9
• 改进内容:
  • 集成 @rneui/themed 组件库
  • 实现自定义主题
  • 优化 UI 组件使用

7.3 加载和认证上下文优化​

• PR: #11, #12
• 改进内容:
  • 改进加载状态管理
  • 优化认证上下文
  • 改进应用加载流程

8. 工具和配置优化 ⚙️​

8.1 环境配置优化​

• 改进内容:
  • 优化环境变量管理
  • 改进配置结构
  • 使用 react-native-config 管理配置

8.2 TypeScript 迁移​

• 改进内容:
  • 将多个 JavaScript 文件迁移到 TypeScript
  • 改进类型定义
  • 提升类型安全

9. 文档整理 📚​

9.1 文档结构优化​

• 改进内容:
  • 整理文档到 doc 目录
  • 创建统一的 README
  • 整理技术文档

9.2 导航文档​

• 新增文档:
  • doc/src/navigation/README.md - 导航系统文档
  • doc/src/navigation/QUICK_START.md - 快速开始
  • doc/src/navigation/MIGRATION.md - 迁移指南
  • doc/src/navigation/INDEX.md - 索引文档

代码统计​

提交统计​

• 总提交数: 80+ 次提交
• PR 数量: 23 个 Pull Request
• 文件变更: 110+ 个文件
• 代码行数:
  • 新增: 10,349+ 行
  • 删除: 3,511+ 行
  • 净增: 6,838+ 行

主要文件变更​

• src/screens/crm/brand/ - 品牌管理模块重构
• src/navigation/ - 导航系统优化
• src/utils/ - 工具函数优化
• src/api/ - API 客户端重构
• src/services/ - 服务层优化

技术亮点 ✨​

1. 性能优化:

   • 实现懒加载和代码分割
   • 使用 MMKV 提升存储性能
   • 优化导航性能

2. 类型安全:

   • 全面迁移到 TypeScript
   • 改进类型定义
   • 提升代码质量

3. 状态管理:

   • 实现页面级状态管理
   • 避免状态污染
   • 提升状态管理效率

4. 代码质量:

   • 组件化和模块化
   • 改进错误处理
   • 优化代码结构

待完成工作 🔄​

1. 品牌筛选功能:

   • 实现标签选择功能
   • 实现创建人选择功能
   • 实现自定义筛选项配置
   • 连接筛选逻辑到品牌列表

2. 测试:

   • 添加单元测试
   • 添加集成测试
   • 性能测试

3. 文档:

   • 完善 API 文档
   • 完善组件文档
   • 完善使用指南

下周计划 📅​

1. 完成品牌筛选功能的剩余部分
2. 实现客户管理模块
3. 优化性能和用户体验
4. 添加测试覆盖
5. 完善文档

总结​

本周主要完成了品牌管理模块的重构和优化，实现了筛选功能的基础框架，优化了状态管理、存储系统、导航系统等多个核心模块。代码质量得到显著提升，类型安全性增强，性能得到优化。为后续功能开发奠定了良好的基础。

包大小​

纷享销客的apk包大小为：885mb；

现在出的apk包大小为：39.6mb;iOS 的 ipa 大小为：9.7MB;