如何用 AI 抓取动态网页数据
「网页抓取」是「龙虾部署大师」技能市场中的网页采集技能：作用是基于 Scrapling，按页面难度分层处理——从简单的 HTTP 请求，到需要 JavaScript 渲染的动态页面，再到受反爬保护（如 Cloudflare Turnstile）的站点，用 CSS、XPath、文本匹配提取目标内容，并能构建支持并发、多会话、代理轮换、断点续爬的爬虫，输出 Markdown、HTML、文本或结构化数据。 技能效果 让它抓取 example.com 时，它真的请求了页面，把标题和正文整理成 Markdown 存成本地文件，并展示出保存下来的内容和摘要。 抓网页的难度，为什么差这么多 "抓个网页"听起来简单，实际难度跨度很大。最简单的静态页面，一个 HTTP 请求就能拿到完整 HTML；但现代 Web 应用大量靠 JavaScript 渲染，直接请求只能拿到空壳，必须等内容渲染出来才提取得到；更进一步，不少站点上了 Cloudflare Turnstile 等反爬保护，普通请求直接被拦。再加上大规模采集时还要处理并发、会话保持、代理轮换、跑挂了能不能续爬——用一套固定的抓法去硬碰各种页面，要么抓不到，要么很快被封。 按难度分层处理 静态页面 get · 一次 HTTP 请求拿全文 动态页面（JS 渲染） fetch · 等内容渲染后再提取 反爬保护页面 stealthy-fetch · 隐身浏览绕过 Turnstile 这个技能能帮你抓到和产出什么 它基于 Scrapling，把抓取按难度分成三层：get 处理静态页面，fetch 处理需要 JavaScript 渲染的动态页面，stealthy-fetch 用隐身浏览应对受反爬保护、需要绕过 Cloudflare Turnstile 的页面——先用轻量方式试，必要时再升级到浏览器抓取。内容提取上，它支持 CSS 选择器、XPath、文本匹配和元素关系定位目标内容。产出格式按文件扩展名决定，可输出 Markdown、HTML、纯文本或结构化数据（如 JSON）。面对大规模站点，它还能构建支持并发、多会话、代理轮换、暂停恢复（断点续爬）和实时统计的爬虫。 目标 URL+ 选择器 分层抓取get / fetch/ stealthy-fetch 提取 + 清洗CSS / XPath文本 / 关系 结构化输出Markdown/JSONHTML/文本 这种"先轻量、再升级"的分层策略是关键：能用 HTTP 请求解决就不动用浏览器，既快又省资源；只有遇到 JS 渲染或反爬时才升级到更重的抓法，避免一上来就用最重的方案拖慢整体。 用前须知 该技能需要 Python 3.10+，并安装 scrapling[all]>=0.4.2 与配套的浏览器安装命令；默认无需 API Key。中国大陆网络环境下可能需要固定 Playwright 版本并配置镜像源。请在合规、获得授权的前提下采集公开网页内容，遵守目标站点的使用条款。 怎么用它 用法是把目标网址、要提取的内容和保存格式用自然语言交给它，抓取层级和选择器策略由它按页面情况选择。例如可以这样对它说： 可以这样对它说 "抓这个新闻站的文章标题和正文，先用 Markdown 保存成本地文件。" "这个页面靠 JS 加载商品列表，要等内容出现再提取价格和库存字段。" "目标站有 Cloudflare 拦截，试试隐身浏览抓指定选择器的内容。" 它适合这些场景：把博客、新闻或文档页面抓成 Markdown 便于阅读归档；现代 Web 应用必须等 JavaScript 渲染后才能提取内容；受反爬保护的页面需要更稳健的浏览器抓取和选择器策略；大规模站点采集需要并发爬虫、断点续爬和实时统计。适合数据工程师、研究人员、自动化开发者、增长分析师，以及需要合规采集公开网页的团队，尤其是从小规模提取扩展到爬虫项目的场景。 大家常问 为什么很多网页直接用 HTTP 请求抓，拿到的内容是空的？ 纯 HTTP 请求只拿到服务器返回的初始 HTML。现代页面常是「空壳」，真正的数据由浏览器执行 JavaScript、再调接口异步填进 DOM。请求端没有 JS 引擎、不会跑后续脚本，所以拿到的是没装修的毛坯，内容自然缺失。 静态网页和动态网页在抓取上有什么区别？ 静态页的数据已嵌在初始 HTML 里，一次请求加解析就能取到，开销低；动态页初始 HTML 只是壳，要等 JavaScript 渲染、DOM 稳定后才提取，需无头浏览器执行，开销高。工程上优先走静态路径，能嗅探内嵌 JSON 就别开浏览器。 网页抓取里说的「反爬」到底是什么，为什么普通请求会被拦？ 反爬是网站靠多维信号判断请求是否「像人」：检查请求头是否完整、单 IP 频率是否过高、行为模式是否机械、能否执行 JS 计算挑战签名。普通请求缺这些特征，就被限流或拦截。合理做法是控制频率、遵守 robots，而非硬碰。 抓取公开网页数据时，怎样才算合规？ 围绕四条原则：检查并遵守目标站 robots.txt 的 Disallow；阅读使用条款，公共可访问不等于可随意复用；两次请求间留足间隔、收到 429 就停；绝不绕过登录、验证码等访问控制。需要破解才能拿到的，就不属于公开数据。 想用上这个技能？ 「网页抓取」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
微信小程序开发怎么优化性能
「微信小程序开发」是「龙虾部署大师」技能市场中的原生小程序开发技能：作用是按官方规范生成原生小程序的页面、组件、API 调用、生命周期和路由代码，用 Data Path 局部 setData、wx:key、rpx、分包等手段优化性能，并预防 iOS 日期、页面栈、原生组件覆盖、隐私协议等常见兼容性 Bug，输出符合规范的代码与处理方案。 技能效果 让它写原生小程序登录页时，它给出 wxml/wxss/js 整套代码，串起隐私授权弹窗、wx.login 取 code 和调后端换登录态三个环节。 原生小程序开发，坑都藏在哪 微信原生小程序有自己一套规则，照搬 Web 经验很容易踩坑。性能上，最典型的是把整个数据对象全量 setData，列表一长、页面一滑就卡；图片不做懒加载、不分包，首屏加载也被拖慢。兼容性上，iOS 的日期格式解析和安卓不一样、页面栈层级有上限、原生组件（如 video、map）会盖住普通视图、跳 tab 页用错跳转 API——这些问题往往要等真机上才暴露。还有审核环节，隐私协议、HTTPS、域名白名单、敏感接口配置没补齐，直接被打回。 全量 setData vs 局部 setData 全量更新（卡） 整对象重传 · 渲染开销大 局部更新（顺） Data Path 只更新变化项 这个技能能帮你写什么、避什么 它把原生小程序的工程规范落进具体代码。生成代码方面，它产出符合官方规范的页面、组件、WXML、WXSS 和 JS，使用 ES6+、Component 构造器，遵循 wx:key、rpx、BEM 等约定。API 封装方面，它把 wx 系列 API 封装成 Promise 或 async/await 风格，避免回调嵌套。性能优化方面，它用 Data Path 做局部 setData、优化列表渲染、图片懒加载和分包加载。Bug 预防方面，它针对性处理 iOS 日期解析、页面栈层级、原生组件覆盖、隐私协议配置等已知坑点。当路由跳转、下拉刷新、上拉加载或生命周期行为不符合预期时，它能定位是哪个 API 用法出了问题。 生成代码页面/组件/WXML 封装 APIPromise / async 性能优化局部 setData/分包 Bug 预防iOS/页面栈/隐私 把局部 setData、wx:key、分包这些规范固化进生成的代码，意义在于性能问题不是写完再优化，而是从第一行代码就避开反模式；同理，隐私协议和兼容性处理前置进开发阶段，能省掉审核被打回、真机才暴露问题的来回。 用前须知 该技能无需专用 API Key。实际开发通常需要微信开发者工具、小程序 AppID 和已配置好的请求域名白名单。代码中不得暴露 appid、secret 等敏感凭据。它面向的是原生小程序框架，不适用于 Taro、Uni-app、Vue 或 React 等跨端方案。 怎么用它 用法是把要实现的页面、组件需求或遇到的问题用自然语言交给它，由它产出符合规范的代码或定位 Bug。例如可以这样对它说： 可以这样对它说 "写一个原生小程序登录页，用 wx.login 并处理隐私授权弹窗。" "这个列表页滚动很卡，改成局部 setData 和图片懒加载写法。" "小程序跳转到 tab 页失败，检查 navigateTo 用法哪里错了。" 它适合这些场景：需要开发登录页、列表页、详情页或自定义组件的原生实现；小程序页面滑动卡顿，要优化数据更新和资源加载；路由跳转、下拉刷新、上拉加载或生命周期行为不符合预期；审核前要补齐隐私协议、HTTPS、域名白名单和敏感接口配置。适合微信小程序原生开发者、前端工程师、技术负责人，以及需要在官方框架内实现页面、组件和性能优化的产品技术团队。 大家常问 为什么微信小程序列表一长、用 setData 更新就会卡？ 小程序是逻辑层与渲染层双线程隔离，setData 要把数据序列化后跨进程传到渲染层再做 diff。列表一长却全量 setData，数据体积大、通信和渲染开销都成倍上升，单次超过约 200KB 就会有可感知卡顿。改成 Data Path 局部更新、只传变化项才顺。 微信小程序为什么要做分包加载，主包 2M 限制是怎么回事？ 主包限制 2MB 是为了保证冷启动时下载、解压够快，给用户"秒开"体验。分包加载把按业务划分的页面拆成子包，启动时只下载主包，用户首次进入分包页面才动态下载对应子包。这样主包瘦身、首屏更快，整包还能放下更多功能（总和有上限）。 微信小程序的云开发是什么，和自己写后端服务有什么区别？ 云开发是小程序生态内的后端即服务套件，把云函数、云数据库、云存储打包好，不用自己买服务器、配域名和 HTTPS、做运维。区别在于：自写后端语言、数据库和网络可完全自定义、查询能力强；云开发省运维但受云函数冷启动、查询能力和网络控制的限制，两者也可混用。 微信小程序用 wx.login 授权登录后，登录态是怎么保持的？ wx.login 只返回临时 code，由后端拿去换 openid 和 session_key，再签发自定义 token 返回前端。前端把 token 存进本地 storage，每次请求带上，登录态就靠这个 token 维持。session_key 留在服务端不下发；token 过期时再静默走一次 wx.login 刷新，用户无感知。 想用上这个技能？ 「微信小程序开发」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 优化提示词
「状态化提示词优化」是「龙虾部署大师」技能市场中的提示词改写技能：作用是自动识别并改进复杂、技术、可复用、需求含糊或精度关键的提示词。它结合 APE、OPRO、DSPy 等模式做多轮优化，冷启动模式可直接套用研究驱动的改写策略，状态化模式则借助嵌入索引的历史样本、相似提示检索、反馈记录和质量评分持续学习，输出优化后的提示词、改进依据、迭代次数和收敛判断。 技能效果 丢给它一句含糊的「把用户反馈整理一下」，它改写成可复用的结构化提示词，补上分类维度、优先级标注、成功标准和后续动作。 提示词写得不稳，问题出在哪 同一个任务，提示词措辞稍有不同，输出就忽好忽坏：需求写得含糊，模型自由发挥太多；约束堆得太满，又变得脆弱、一改就崩。更麻烦的是缺少积累——每次都从头调，调好的版本没沉淀下来，下次遇到类似任务又得重来。对于代码生成、分析报告这类需要稳定结构和验收标准的任务，提示词不稳定，直接拖累产出的可靠性。 含糊提示 自由发挥太多 堆满约束 脆弱、一改就崩 清晰、可测量、可复用 约束简洁有效 这个技能能帮你优化什么 它把"凭手感调提示词"变成"有方法、可积累的优化过程"。核心能力有四块：一是识别复杂、多步骤、技术输出、模板和精度关键型的提示词，判断哪些值得优化；二是调用优化流程，生成改写版本、改进说明和迭代建议，并控制迭代次数与收敛条件，避免过度优化反而变脆；三是在状态化模式下，基于历史向量检索、相似提示、反馈记录和成功率持续学习，让后续改写越用越准；四是结合 APE、OPRO、DSPy 等研究驱动的策略，把含糊需求改写成清晰、可测量、可复用的指令。优化结果会附上改进依据和迭代次数，让你看清"为什么这样改"。 原提示词含糊/脆弱 多轮优化APE/OPRO/DSPy+ 历史检索 迭代收敛 优化后提示词清晰 / 可测量附改进依据 用前须知 冷启动模式无需安装即可使用。若要启用状态化学习（基于历史样本持续改进），需要 Node.js 18+、Docker、Qdrant、Redis 以及 prompt-learning MCP，并配置 OPENAI_API_KEY 用于嵌入与评估。 怎么用它 用法是把你要优化的提示词和期望的稳定效果用自然语言交给它，它会改写并说明依据。例如可以这样对它说： 可以这样对它说 "把这个长任务提示词优化成可复用版本，并设清楚成功标准。" "这段代理提示老跑偏，按历史效果压缩约束，减少无关发挥。" "改进这个代码审查提示词，让输出稳定覆盖关键风险点和缺失测试。" 它适合这些场景：要把含糊需求改写成可复用的系统提示词或任务模板；代码生成、分析报告或结构化输出需要更稳定的约束和验收标准；长期项目希望记录提示词表现并基于成功案例持续改进；复杂代理流程要在不增加脆弱性的前提下提升指令清晰度。 大家常问 为什么同一个任务，提示词措辞稍微改一下，模型输出就忽好忽坏？ 大模型每次调用都是无状态的独立计算，没有对上一次输出好坏的记忆，措辞稍变就走到不同的生成路径上，输出自然不稳。状态化提示词优化的做法是在调用之间建一条反馈回路：把历史输入、输出和评分累积起来，挑高分样本做滚动 Few-shot，再用反思-改写循环抑制随机波动，让"忽好忽坏"收敛成稳定输出。 什么是提示词的冷启动模式和状态化模式，它们的差别是什么？ 冷启动模式是每次都从零构建提示词，不查、不留任何历史，效果完全取决于本次写得好不好。状态化模式则把每次提示词、响应和质量评分记录下来，建嵌入索引和成功率统计，新任务先检索相似的高分历史样本作参考。差别在于学习能力：冷启动每次原地重来，状态化越用越准，但需要存储和检索基础设施。 为什么提示词不能一次写好，需要多轮迭代和收敛判断？ 因为你写提示词时脑子里的"理想输出"模型并不知道，模型对模糊指令的默认倾向也要等它真的产出文本才能看见。多轮迭代实际上是用实测数据反向修正你对模型的假设：上下文累积灌入你的标准，反思-改写分离诊断和修复，A/B 替换让数据决定哪种措辞活下来。收敛判断（连续几轮改进幅度低于阈值、评分达标、Token 预算耗尽等）则避免越改越脆的过度优化。 怎么判断一段提示词是『含糊型』还是『精度关键型』，对应的改写策略有什么不同？ 把提示词套入「80% 正确是否仍然有用」这一问：写产品介绍、做主观分析这类回答"是"的属于含糊型；代码生成、信息抽取、SQL 查询这类回答"否"的属于精度关键型。含糊型改写重点在风格引导和方向一致——上下文用追加式累积偏好，Few-shot 选风格范例，预算可宽松；精度关键型重点在压缩误差——规则约束严格优先于历史，Few-shot 滚动覆盖易错边缘案例，强制开启链式思维做审计追踪。 想用上这个技能？ 「状态化提示词优化」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 学会 Git 常用命令
「Git 基础操作」是「龙虾部署大师」技能市场中的版本控制助手技能：作用是把常用的本地 Git 命令和协作流程整理清楚并安全执行，覆盖初始化、克隆、配置用户名邮箱、查看状态、暂存、提交、修订提交、查看差异，以及分支创建切换删除、合并、冲突检查、远程仓库管理、fetch、pull、rebase、push 和安全强推。它把这些操作规范化，并整理命令输出便于查看。 技能效果 让它演示查看仓库改动时，它真的初始化了一个 git 仓库、造了四个文件并改动一部分，再用命令展示出已暂存、未暂存、未跟踪三种状态和当前分支。 Git 命令记不牢，问题出在哪 Git 的日常痛点不是不会用，而是命令零散、易记错，且部分操作有破坏性。查状态、看差异、暂存、提交、改提交、建分支、切分支、合并、推远端——每个动作都有自己的参数和细节，偶尔用一次就要翻文档。更要紧的是，rebase、强推这类操作一旦用错，可能覆盖他人提交或丢失历史。结果是：简单操作要查，危险操作不敢轻易动，效率和安全两头都打折扣。 本地 Git 工作区流转 工作区 add 暂存区 commit 本地仓库 push 远端 这个技能能帮你做哪些 Git 操作 它把本地版本控制的常用动作整理成一套可以放心调用的能力，并附带安全约束。基础层面，提供初始化、克隆、全局配置用户名邮箱、状态检查和提交。日常层面，覆盖暂存、差异查看、提交修订，以及分支的创建、切换、删除和管理。协作层面，处理合并、冲突检查、远程仓库添加、fetch、pull、rebase、push，对安全强推这类有风险的操作格外谨慎。它还会清理命令输出，按状态、日志或分支列表选择合适的展示格式，让结果一眼能读懂。它定位在常用命令与基础协作流程，更复杂的历史搜索、stash、标签、cherry-pick、子模块等会指向扩展文档。 基础init/clone/commit 日常diff/分支/改提交 协作merge/pull/push 安全强推谨慎/输出清晰 用前须知 该技能无需 API Key，但需要本机已安装 Git。涉及远程仓库推送或私有仓库时，需要额外配置对应平台的认证（如 SSH Key 或访问令牌），否则推拉操作会因权限不足而失败。 怎么用它 用法是把当前要做的版本控制动作用自然语言说清楚，不必记参数，由它选用安全的命令并整理输出。例如可以这样对它说： 可以这样对它说 "看一下当前仓库哪些文件改过、哪些还没暂存，顺便告诉我当前在哪个分支。" "把这次改动提交成一条记录，提交信息写修复登录，不要改上一条提交。" "新建一个 feature 分支，把本地改动推到远端并设置上游。" 它适合这些场景：新项目要初始化仓库、配置用户信息并完成第一次提交；开发者要创建功能分支、切换分支、合并并处理冲突；需要查看未暂存或已暂存差异、确认提交范围是否正确；团队协作时设置远程仓库、拉取更新并推送新分支。 大家常问 git 的工作区、暂存区和本地仓库到底是什么关系？ 工作区是你正在编辑的文件目录，可自由增删改；暂存区是 .git/index 里那张「下一次提交的清单」，由 git add 把工作区改动登记进来；本地仓库是 .git/objects/ 里的不可变提交快照，由 git commit 把暂存区那张清单永久写入。HEAD 则是指向当前分支最新提交的指针，决定 commit 的父提交是谁。 git merge 和 git rebase 都能合分支，本质区别是什么？ merge 是追加一个有两个父提交的合并节点，原有的两条分支提交一字不改地保留下来，历史呈分叉拓扑；rebase 是把当前分支的提交挨个搬到目标分支顶端，重新生成全新哈希的提交，历史变成一条直线。前者不改写历史、可被 revert 整体撤销，后者重写历史，已推送到远端共享的提交不要 rebase。 为什么 git push --force 被视为危险操作？ 普通 git push 会做快进检查，若远端有本地没有的提交就拒绝推送，保护远端历史完整性。--force 直接跳过这道检查，把远端分支引用强行指向本地 HEAD，远端那些你没拉到的提交立刻从引用图里被切断，沦为悬空对象，等 git gc 一跑就永久丢失。别人在那段历史上的工作也会一起被覆盖。 git reset 和 git revert 都能撤销改动，怎么区分？ reset 是把当前分支指针往回挪，属于改写本地历史，被甩开的提交进入 reflog 等待回收；--soft 只挪 HEAD、--mixed 还重置暂存区、--hard 连工作区一起回退。revert 是基于要撤销的那个提交生成一条反向变更的新提交追加到末尾，历史不被改写，安全可分享给协作方。共享分支用 revert，本地未推送用 reset。 想用上这个技能？ 「Git 基础操作」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
AI整理治疗方案怎么做
「治疗方案整理」是「龙虾部署大师」技能市场中的临床文档整理技能：作用是把病情、诊断、目标、干预和随访信息，整理成结构化、可执行、以患者为中心的治疗计划文档，覆盖通用医学、康复、心理健康、慢病、围手术期和疼痛管理等专科，支持一页版到标准版的不同复杂度，并可渲染成专业 A4 PDF。 技能效果 按一份糖尿病合并高血压的病历整理方案，它做出可30秒扫读的首页指标对照表，并按SMART写清短期治疗目标。 整理治疗计划，琐碎在哪？ 把一份治疗方案写成规范、能交付的文档，是临床和康复团队的高频工作，琐碎也都在细节上。同一份计划要把阶段目标、干预措施、监测指标、随访安排和转诊节点都列清楚，还得让关键安全阈值一眼可查；目标要写成可量化、可执行的形式，而不是一句"加强康复"。 另一个常被忽略的问题是格式一致性：中文临床资料里常混入英文模板的占位内容，PDF 排版又要兼顾首页可扫读和整体专业度。这些都不是医学判断本身，却实实在在占用时间。 散落的信息 → 结构化计划 病情诊断 治疗目标 干预 / 随访 治疗计划文档 SMART 目标（可量化） 分阶段干预 + 监测指标 关键安全阈值（醒目） 随访 / 转诊节点 这个技能能帮你做什么？ 这个技能把治疗计划的整理拆成几个可控环节：先做环境检查和复杂度判断，按病种复杂度和专科类型选择一页版或标准版模板；再生成模板（LaTeX 或 JSON）并填充 SMART 目标和干预措施；随后做完整性验证，核对安全要点、药物记录、随访安排、SMART 目标和语言一致性；最后通过 LaTeX 或内置 Python 路线渲染成专业 A4 PDF。对复杂治疗路径，还可加入流程图、时间线或关键决策节点的图示。 环境检查 复杂度判断 模板 + 内容 完整性验证 渲染 PDF 语言一致 · 隐私合规 · 安全阈值清晰 整个过程强调语言一致、隐私合规、引用克制，让关键安全阈值清晰可查，输出便于团队评审和交付的临床计划文档。 用前须知 它整理出的是结构化文档，仅作临床记录与沟通参考，不构成正式医疗建议，更不能替代执业医师的诊断与决策；所有方案必须由具备资质的医疗专业人员复核后才能用于患者。技术上首次运行需执行 setup.py 检查依赖，需要 Python 环境；PDF 走 LaTeX 或内置 Python 渲染路线，后者依赖 Playwright/Chromium。 怎么用它？ 用法是把病历或方案要点，连同对文档形式的要求，用自然语言交给它。例如可以这样对它说： 可以这样对它说 "按这份病历整理糖尿病治疗方案，目标和随访写清楚，首页能扫读。" "为术后膝关节康复做一页版计划，训练里程碑按周写可量化数值，随访写明。" "这位慢性腰痛患者要多学科方案，药物风险和复诊安排单独标出来。" 它适合这些场景：医生要把糖尿病、卒中康复或慢性疼痛方案整理成专业 PDF；护理或康复团队需要清晰列出阶段目标、干预、监测和转诊点；中文临床资料需要保持同一语言、避免混入英文模板占位；复杂治疗路径需要加入流程图、时间线或关键决策节点图示。它服务于标准化文档的准备，临床决策权始终在专业人员手中。 大家常问 治疗方案里的 SMART 目标是什么意思？为什么医生在写治疗计划时偏向这种写法？ SMART 指 Specific（具体）、Measurable（可量化）、Achievable（可实现）、Relevant（相关）、Time-bound（有时限）。它把"加强康复"变成"12 周内 6 分钟步行距离从 200 米提至 350 米"这种可对照的标尺，让多学科团队对同一目标的"达成与否"判断一致，复诊评估也有量化依据。AI 仅供参考，治疗目标需医生结合个体情况设定。 治疗计划里的一页版和标准版有什么区别？分别在什么场景下更合适？ 一页版严格控制在 A4 一页，只保留直接改变临床决策的关键信息，适合方案明确的常见病、患者随身携带、复诊快速对照。标准版通常 3–6 页，包含目录、分章节的诊断依据、分阶段干预、监测计划与关键指南引用，适合多学科协作、合并症分层、转诊交接和档案留存。具体选用以医生判断为准。 为什么 AI 整理出的治疗方案必须由执业医师复核后才能用于患者？这种边界来自哪里？ AI 是基于语料的统计归纳，不具备体格检查、辅助检查解读和因果推理能力，也无法系统性排除主动脉夹层这类危急诊断。这条边界由执业医师法的资格制度、AI 的幻觉与知识截止限制、"不伤害"伦理三层共同决定，所以 AI 输出仅供参考，最终诊断与处方必须由执业医师完成。 治疗计划里的随访和复诊是同一件事吗？两者有什么核心区别？ 不是同一件事。复诊由患者发起，必须到院挂号、由医生重新接诊并可开处方，是一次完整的诊疗闭环；随访由医生或机构主动发起，形式可以是电话、线上问询、远程数据回传或护士回访，目的是追踪病情、康复指导和依从性管理，不一定构成诊疗行为。具体安排以主诊医生医嘱为准。 想用上这个技能？ 「治疗方案整理」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
如何用 AI 做 iOS 应用开发
「iOS 应用开发」是「龙虾部署大师」技能市场中的 Apple 平台开发规范技能：作用是提供 UIKit、SnapKit 与 SwiftUI 的开发指南。给定应用场景、界面需求和技术栈后，它输出组件选型、导航结构、安全区域、触摸目标、Dynamic Type、深色模式、无障碍、权限请求和系统集成的检查清单，强调 HIG 合规、系统手势保留和语义颜色使用，帮助减少移动端常见实现问题、提升上架质量。 技能效果 让它做 SwiftUI 记账首页时，它用 @ScaledMetric 和系统语义色处理了深色模式与大字号无障碍，金额标题配 minimumScaleFactor 确保超大字号也不截断。 iOS 应用被打回，往往栽在平台规范上 iOS 应用的难点常常不在功能本身，而在 Apple 平台的一整套隐性规范。UIKit、SwiftUI、SnapKit 之间该选哪个、能否混用，组件选型一开始就要想清楚；界面要避开刘海和底部安全区、按钮热区不能太小、间距要守住 8pt 体系；Dynamic Type 放大后文字不能截断、深色模式下颜色要用语义色、VoiceOver 要能正常读出。这些 HIG 要求平时容易被忽略，却直接关系到体验质量和能否顺利上架。 ↑ 顶部安全区 语义色 · 深色模式 Dynamic Type 不截断 触摸目标 ≥ 44pt ↓ 底部安全区 / 系统手势 这个技能能帮你把住哪些关 它把 Apple 平台体验质量拆成一组可核对的检查项。组件层面，指导 UIKit、SwiftUI 和 SnapKit 之间的选型，UIKit 项目要迁移或混用 SwiftUI 时也能给出统一决策。布局层面，校验安全区域、触摸目标和 8pt 间距体系，避免按钮热区和安全区出问题。体验层面，覆盖 Dynamic Type、深色模式和 VoiceOver 要求，确保放大字号、暗色和读屏都正常。集成层面，提供导航、权限请求、生命周期和系统集成的检查清单。它贯穿 HIG 合规、系统手势保留和语义颜色使用，从新建界面到上线前核对都能搭得上。 组件选型UIKit/SwiftUI 布局校验安全区/8pt/热区 体验合规字号/暗色/读屏 系统集成导航/权限/生命周期 用前须知 该技能仅支持 macOS。需要安装 Xcode、Swift 5.9 及以上版本，命令行工具通过 xcode-select 安装；CocoaPods 可选，无需 API Key。在非 macOS 环境下无法进行 iOS 构建与调试。 怎么用它 用法是把应用场景、界面需求和技术栈用自然语言说清楚，由它给出组件决策和检查清单。例如可以这样对它说： 可以这样对它说 "做一个 SwiftUI 记账首页，兼顾深色模式和大字号，文字别截断。" "把这个 UIKit 列表页改成 CollectionView，支持搜索和空状态。" "上线前检查这个 iPhone 界面，别让按钮热区和安全区出问题。" 它适合这些场景：新建 iPhone 应用、需要确定 Tab、导航栈和页面结构；已有界面要符合 Apple HIG、无障碍和深色模式规范；UIKit 项目要迁移或混用 SwiftUI、需要统一组件决策；上线前核对权限请求、动态字体和系统交互行为。 大家常问 SwiftUI 和 UIKit 的差别是什么？ UIKit 是命令式框架，靠开发者手动创建 UIView、配置 Auto Layout 约束、在回调里调 setText 和 reloadData 来同步状态；SwiftUI 是声明式框架，用 @State、@Published 等数据源描述 View body，框架按状态自动差分重绘。底层的 App 生命周期、签名和上架审核两者完全共享，差异集中在"谁来驱动 UI 更新"这一层。 iOS 开发里为什么要严守 Safe Area？ Safe Area 是 iOS 系统按当前设备形态和界面状态动态计算的安全可视区域，排除了刘海、状态栏、Home Indicator 和系统手势区。来电状态栏、横竖屏切换、iPad 分屏都会触发 safeAreaInsets 变化；不绑定 Safe Area 的硬编码布局会被遮挡或与系统手势冲突，App Review 4.1 明确把这点作为审核检查项。 Dynamic Type 是什么，为什么 iOS 应用要适配它？ Dynamic Type 是 iOS 7 起的系统级文字大小自适应：用户在设置里调整字号后，系统通过 UIContentSizeCategory 通知前台 App 重新计算字号。UIKit 用 UIFontMetrics 加 adjustsFontForContentSizeCategory 自动响应，SwiftUI 用 @Environment(\.sizeCategory) 与 @ScaledMetric 联动。不适配会在大字号下文字被截断，也会在 App Review 的无障碍审查中被追问。 iOS 应用为什么要适配深色模式？语义色和写死的固定色值差别是什么？ iOS 13 起系统会通过 UITraitCollection 注入当前外观模式，深色模式不是开关而是渲染管线的输入参数。语义色（如 label、systemBackground）写在 Assets Catalog 的 colorset 里，编译期落进 .car 文件，运行时由 CoreUI 按当前 userInterfaceStyle 自动选色；写死的固定色值不会随系统切换，深色模式下会出现对比度塌陷和可读性问题。 想用上这个技能？ 「iOS 应用开发」就在「龙虾部署大师」的技能市场里，打开 技能市场 就能一键安装使用。 还没装龙虾？先 一键部署「龙虾部署大师」，在本地跑起来后再装技能即可。 注：技能的实际效果与所选用的 AI 模型能力有关，不同模型下的表现可能存在差异。
提示